> > Interesting idea. How about just always forcing a MINOR part, setting > > to "0" if upstream doesn't have one? > That'd declare regular releases as MAJOR.0 in the version field, which > I'm not sure if we want that. In the case of random commits I'm less > reserved, as they don't correspond to releases anyway. I see your point. In fact, upstream releases start with MINOR part "a" and "count up" through the letters over the course of a year. It's a pretty simple scheme. For example, J 901 started at "j901-release-a" and ended at "j901-release-f". When I originally wrote this package, I noticed that the release tag for the first J 902 was "j902-release", and so treaded MINOR as potentially optional. However, after checking upstream's forums, this looks to just be a git tag mishap. How about we just go ahead and treat MINOR as mandatory as well? > > If you have a better idea, I am all ears. > You could define that file-union right after ijconsole. If you want to > golf even more, you could define ijconsole inside that file-union, i.e. > (define jsoftware-aux-files > (file-union "jsoftware-aux-files" > `(("profile.ijs" ,(search-aux-file ...) > ("ijconsole" ,(program-file ...)))) > > I'm not quite sure if you want to use jsoftware-aux-files directly as > input or whether it's wiser to stuff it into another union like > (file-union "jsoftware-aux-input" `(("aux" ,jsoftware-aux-files))). > search-input-file will probably do the right thing regardless. > The new style should also still work with assoc-ref, it'd just be > weirder to look at. Lastly, you could code up a (search-file-input) > just in case; I'm not sure if we have one already. The file-union seems like a cludgy workaround to me. What we really want is an easy, direct way to get handles on the input files. Heck, program-file objects already have a name property; why can't we use that? Attached patches are a proof-of-concept. That said, if this is going to turn into a big rabbit hole, can we just munge the J package inputs into whatever you think is best?