Re: some questions about GUIX

[Ricardo Wurmus]

Sam Halliday <address@hidden> writes:

> Does this mean that you have a GUIX package for every jar?

Some packages may provide more than one jar archive.  This depends on
what the build system prescribes.  For every *project* there will be at
least one jar, though.

> If so, can
> you have multiple versions of the same jar installed at the same time?

Yes!  This is a core feature enabled by functional package management.
We treat packages as if they were pure functions in that the exact same
set of inputs (source tarballs, compilers, libraries, and their own
inputs, and the inputs of those inputs, etc...) produces the exact same
output.  Instead of computing the output from scratch each time we want
to use the value (e.g. as an input to another package or in a profile)
we can cache or memoise it.  We do this by storing the unique output
artifact for a given bag of inputs in /gnu/store; outputs are prefixed
with a unique hash that is computed from all inputs.

Installing a package then is little more than the act of linking
individual items from the store into a profile.  We can store any
package output in /gnu/store because they all have their very own
directory; they don’t overlap.  Thus we can install/link different
versions into different profiles.
 
> Support for multiple versions of a library will be necessary as it is
> not always a simple case of bumping the version to use a library: many
> libraries introduce breaking changes at both source and binary level.

Correct.  We don’t have a problem with this as we never install anything
into a “global” namespace (such as /usr, /lib, or whatever).

> Will you be using the same version names as the official upstream
> binaries? I strongly recommend against doing this. The convention in
> corporate environments is that rebuilds of jars incur a postfix to their
> version. E.g. a rebuild of guava 18.0 (even with no changes to the
> sources) would be 18.0-guix1. Of course, there is no way for you to know
> that jars are not being loaded by name at runtime through the
> classloader, so you introduce further opportunity for bugs here.

FWIW Debian builds Java libraries from sources, too, and they do not
rename the resulting jars.

There is really no need to do that in Guix anyway, because installing
these jars is not going to affect global state — they are not installed
in well-known global directories, so they cannot be “picked up” by
accident.

There is, of course, one potential issue with building Java stuff on
Guix that I haven’t assessed yet.  I don’t yet know if there’s something
in the Java world that’s similar to the RUNPATH feature in native
applications, or if visibility of jars is determined exclusively by the
clunky CLASSPATH environment variable instead.  If there is no way to
“link” jars explicitly by their full path, then dependencies need to be
propagated and applications may need to be wrapped in an appropriate
CLASSPATH, which is somewhat inelegant, but not a real problem.  (This
is done for Python, R, Perl, and Ruby applications in Guix already,
because these languages control module visibility primarily through
environment variables.)