Re: Reproducible environments

[Konrad Hinsen]

Hi Pjotr,

First of all, thanks for your explanations!

 > At this point (correct me if I am wrong), the route to take is to
 > checkout a commit of the Guix source tree (with packages). The SHA
 > value is captured on Hydra in the build itself. That is the only way
 > to fully reproduce GUIX as a point in time. And use guix package using
 > that tree.

OK, so the procedure is:

 1) Check out a specific commit of Guix.
 2) Make a manifest that defines a profile
 3) Use "guix package" with options
    -p  for defining the profile
    -L  for pointing to the directory containing the package descriptions
    -m  for choosing the manifest

I could then archive 1) and 2) for reproducing the environment later. That
sounds quite doable.

 > > Problem #2: What if my profile contains packages from several
 > > Guix commits (typically for getting specific older versions)? Or
 > > if it contains packages defined outside of the Guix distribution,
 > > in Guile modules on GUIX_PACKAGE_PATH?
 > 
 > You'd have to create a new profile that is tied to above build to be
 > fully reprocible. Managing multiple profiles is pretty
 > straightforward (using the -p switch). I use a compile profile for
 > guix, for example, containing gcc etc.

I already found out that creating profiles is easy, which is a nice feature.
But I may well need to mix different Guix commits in one and the same profile.

Here's an example (a simplified version of the real situation that motivated
me to check out Guix):

   - I need to use Program X that depends on libraries A and B.
   - The current versions are A-1.1 and B-42.0.1.
   - X requires "1.0 or later" for A but "41.*"  for B, because
     version 42.* of B is not fully backwards compatible.

If there's no Guix commit that has both A and B in the required
version range, then the easiest way to get what I need is to use an
older Guix commit for installing B than I use for A.

In fact, the only other alternative I see is to add a package definition
for the old version of B to a later Guix commit. That's likely to be
much more difficult.

 > Note that you can also tar ball a binary package with all its
 > dependencies (using guix archive) and distribute that. That is 
 > reproducible at the binary level. That may be more useful for end-users.

That's what I would use to share environments with collaborators. But
I wouldn't download binaries from a stranger, and I don't expect
others to have a different attitude.

Konrad.