[bug#48463] gnu: Add j.

[Leo Prikler <leo.prikler@student.tugraz.at>]

Hi,

Am Montag, den 24.05.2021, 22:37 +0900 schrieb elaexuotee@wilsonb.com:
> > Are fat binaries the accepted HPC way?  I'm not up-to-date to this.
> 
> I believe so? Don't quote me on that though. For this particular
> package the
> overhoad is just ~8MB, so I don't think it's much of an issue either
> way. It
> would probably be more of a hassle to split j into a package for each
> variant.
In that case it will probably be fine.

> > Both sound like good ideas, although I'm a little less sure about
> > the
> > texlive one.  Would a meta-package like gnome also be acceptable?
> 
> A metapackage is certainly practical. The entire set of J addons
> currently weighs in at a whopping 50MB. hehe. However, there are
> about 125 addons in total, so it simply feels "more correct" to let
> the user also choose just the addons they want, which I think would
> require something like jsoftware-union.
> 
> That said, either way, an "all batteries include" package would be
> good to have, and since this is way easier than packaging the addons
> separately, I'll definitely work on the metapackage first.
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.)

> > As above, I'd prefer if it was one procedure and one package
> > pointing to the latest j80x, assuming all of our added patches can
> > also be applied to earlier versions.
> 
> Yeah, that would definitely be ideal.
> 
> Unfortunately, it's not so straigthforward. The the "major versions"
> are the xxx part of jxxx-y, with large changes between each, e.g.
> j902 introduced and non-compatible API change over j901. So, from a
> pure J user perspective, having all jxxx versions available is ideal.
> 
> However, each version seems to require its own set of build flags and
> sometimes version-specific patches (like in the j901 case). We
> probably don't want to push those settings out into user manifest
> specs.
> 
> On the other hand, there are already 10 versions from j801 to j903.
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]?

> > > +(define make-jlib
> > > +  (match-lambda
> > > +    (($ <jlib-build-configuration>
> > > +        builder jversion revision hash type patches extra-inputs
> > > extra-envars)
> > Please try to use keyword arguments.
> 
> Actually, maybe these "build configuration" records could solve the
> above "too many versions" problem. We could offer only the latest J
> (and J beta?) packages in the repo, but let (gnu packages jsoftware)
> export a set of "default configurations" for old versions to be used
> with the make-j procedure.
I don't think there's much to be gained if we provide packages without
packages.

> Any particular reason to avoid using records though? Currently, its
> letting us share configuration options between j902 and j903 that
> don't work in j901.
> Personally, I thought this felt like a nice declarative, scheme-y way
> to go, but my Scheme is still very amateurish. Definitely wanting to
> rectify any strange ideas I may have.
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).

> > > +       (properties `((jversion . ,jversion)
> > > +                     (jrevision . ,revision)
> > > +                     (jtype . ,type)))
> > Are those used anywhere?  Can jversion and jrevision not be parsed
> > from (package-version jlib)?
> 
> The make-j procedure uses them. We'd have to parse out these from
> both the version string and package name with a what's essentially
> the inverse of the jname procedure. I found it a lot more readable
> and less hassle to just propagate this data directly.
> 
> However, if there's a particular reason why using properties is
> problematic, I'll try to see what I can do.
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).

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.  (Note,
that we typically use "-next" for that, however).  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.

Next, should ijconsole not simply be a package like jlib (both properly
prefixed with jsoftware- of course)?  Then you can take whatever
version bits you need from the package version itself.

Regards,
Leo

[1] https://gitlab.inria.fr/guix-hpc/guix-past