Here's a long-needed update. > > For now, instead of messing with the union, would it make sense to > > just create a (non-public?) jsoftware-addons package that contains > > all addons and point jlib at those? > > Are those addons data packages or can they be compiled without needing > jlib? If they're pure data, then you can pack them up and refer them > as you wanted to, if not, you first have to create jlib-minimal without > them, then package up everything and finally do jlib. They're pure data, which is nice. The J package manager also lets users install arbitrary addons from GitHub, so packaging up the official addons would lock the `addons/' directory under the non-writable store, meaning that we probably also want an importer. I am working on that, but instead of keeping this package in lingo much longer, maybe we can release sonner and consider the addon package code a separate issue? > Oh, and one thing that was previously ignored is that using XDG > standards for things we can't simply put in the store (like > configuration if it needs that) is preferable to having a ~/.j > directory. Excellent point. Fixed. > > > That's less than the number of Rust versions we need just for > > > bootstrap, but still a few too many in my opinion. Are all of > > > those still used in production or would it be wiser to to put some > > > of them into Guix-Past [1]? > > People are also still running ancient versions of Debian. Python 2 has > officially reached end of life, yet it is used as well. At some point > we do have to declare software that people are still using as old :) Sounds sane. I will probably eventually work on getting the j80x series in Guix and the really ancient ones in Guix Past. However, that will be a future task for myself. > > > Having keyword lists is also nice and declarative, but more > > > importantly, it lets you call the function as a normal function > > > without having to worry about constructing some record in a > > > particular way. The configuration you're using doesn't have a > > > specific setting? Just override it with your own. It's as simple > > > as calling (append old-config extra-config). > > ... > Yup. Now using keyword lists. > > > I find this way of mistreating the version field very > > > weird. You're not adding anything new by doing this and you're not > > > making anything more secure (I'd argue, that it's less secure, > > > because you could update the version and forget about the property > > > or vice versa). The code overall is a lot more straightforward now. How does the versioning stuff look now? > > My thinking was that 4 means we want a separate *-beta package, > > meaning that the version field should probably just look like > > "-". > > Additionally, relating back to the above discussion about multiple > > versions > Sounds good, though . would be equally acceptable. > Your call. > > > 5) It would be nice to be able to install the latest j901 without > > having to > > know that this corresponds to patch level f, i.e. currently > > j@901-f. > I think `guix build j@901' ought to resolve this automatically. It turns out that the j@901 specification only gets recognized with versions strings of the form ., so going with that. > > > First of all, do you even need all this info? `j' is an > > > objectively bad name > > > for a package. `j-beta' is not better in any way, it only avoids > > > the user installing a potentially unstable "J" package. > > > > Yeah, "j" is pretty short but it does mirror "r". I'm agnostic about > > package name, though. Suggestions welcome. > Fair enough, though this remains a problem for single letter programs > in which others would likely want to claim the letter as well. R has > the benefit of being old and well-known enough, it would probably be > rlang otherwise (not to be confused with erlang). J has been around from the 1990's :D That said, I went ahead and named it `jsoftware-j', since despite age, J is still pretty obscure, and there's not much of a good reason to monopolize a single letter name. > > I see what you mean in a general sense but not quite how to apply it > > in this case. I am all ears if you have a simpler, cleaner solution > > that addresses the constraints listed above! > I think the cleaner solution here is to not store those properties in > the package, but still having them as parameters to the make-j function > call. Happily, the new package re-organization was able to get rid of these properties. > > > Next, should ijconsole not simply be a package like jlib (both > > > properly prefixed with jsoftware- of course)? > > > > This is effectively what make-j does, no? ijconsole needs to know the > > path to jlib, so make-j points it at the correct one and wraps > > everything up into a package. > I don't really understand why those needs to be done in two steps > however. ijconsole could already contain the fully functioning j > program. Or partially functioning if we account for addons. As you can see, there's no need for a separate ijconsole package any more. Instead, `ijconsole' is just defined as a program-file that becomes an input to jsoftware-j. It is also worth pointing out the convenience procedure `jsoftware-ijconsole-symlink'. Basically, it p Anyway, let me know what you think!