[bug#48463] gnu: Add j.

[Liliana Marie Prikler <liliana.prikler@gmail.com>]

Hi,

Am Dienstag, den 25.05.2021, 12:57 +0900 schrieb
elaexuotee@wilsonb.com:
> As always, thanks for the quick turnaround.
> 
> Leo Prikler <leo.prikler@student.tugraz.at> wrote:
> > stuff-union usually implies, that stuff can't just be put into a
> > profile and expected to work (like texlive), whereas in other cases
> > (e.g. the gnome metapackage) people can use its parts on their own
> > provided that they have the right combination (which typically
> > implies having icons etc.)
> 
> Oh, okay.  For some reason, I was just imagining "metapackage" to
> mean "all batteries included", but your description makes a lot more
> sense. In this case, having addons without the J interpreter is
> pretty useless, so IIUC a jsoftware-union makes more sense than a
> metapackage in this case?
> 
> Just to be clear, J looks for addons at a path burned into
> $store/...-jlib-$version/etc/j/profilex.ijs.  Currently, that points
> to $HOME/.j/$jversion/addons, but we'll need to change that to a
> single store output path that contains the union of all desired
> addons, hence why I was thinking the *-union approach is needed.
> 
> 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.

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.

> > 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]?
> 
> Oh cool. Guix Past might be a better solution! Thanks for sharing.
> 
> I don't have any solid data, since "in production" J is mostly
> dominated by the financial sector from what I hear, but just going by
> my impression from lurking on the J mailing list, the j80x series
> (and even earlier non-free versions) does still have a user base.
> 
> Personally, I just want to make these older versions available to the
> community but am agnostic about the *how* so will defer to whatever
> you (and others) think is best.
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 :)

> > 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).
> 
> Oh! (append old-config extra-config) is exactly the kind of thing I
> was trying
> to achieve; however, I'm not sure I quite grok the usage you are
> describing.
> Something like this?
> 
> (define* (proc #:key foo bar) ...)
> (define old-config '(#:foo 0))
> (define extra-config '(#:bar 1))
> (apply proc (append old-config extra-config))
Yup.

> > 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).
> 
> I agree the version stuff is a bit crappy.  It's something that got
> munged badly over time and deserves more thought.  Here are the
> issues I'm trying to solve:
> 
>   1) The source URLs look like ../j<version>-<type>-<patch> or
>      ../j<version>-<type>, where <type> is either "beta" or
> "release", and
>      depending on whether a patch-level exists;
>   2) The type string ("release" or "beta") is a build setting; and
>   3) ijconsole installs to something like ../bin/ijconsole-902,
> without
>      including the patch-level, like ../bin/ijconsole-902-b.
>   4) Users should probably be able to easily install the latest J
> release as
>      well as J beta concurrently without caring about exactly which
> version
>      these are.
> 
> Those imply that <version>, <type>, and <patch> are indeed handled
> separately, no matter concrete method utilized.
Those four issues do call for separate keyword arguments, but they need
not necessarily be reflected in the version string.  You can have two
packages with the same version, but different hashes in Guix.  

> 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.

> > 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).

> > (Note, that we typically use "-next" for that, however).
> 
> Thanks for pointing out this convention.
> 
> > However, this info is meaningless when hardcoded into a
> > procedure.  You can just inherit from the package that's generated
> > and override the name as needed.
> 
> 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.

> > 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.

Cheers!