[bug#48463] gnu: Add j.

[elaexuotee]

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
> > "<version>-<patch>".
> > Additionally, relating back to the above discussion about multiple
> > versions
> Sounds good, though <version>.<patch> 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 <version>.<patch>, 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!

0001-gnu-Add-j.patch
Description: Text Data