[bug#48463] gnu: Add j.

[elaexuotee--- via Guix-patches via <guix-patches@gnu.org>]

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?

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

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

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

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

   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.

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

> (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!

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


Anyway, thanks again for taking a look!