Re: Reproducible environments

[Pjotr Prins]

On Tue, Oct 06, 2015 at 06:59:44PM +0200, Konrad Hinsen wrote:
> 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.

Create multiple packages. Such as we do for Ruby 1.8, 2.1 and 2.2. You
can specify specific dependencies on each using one git checkout.

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

Agree. But sometimes convenience wins. Also the binary tar balls may
help with rapid deployment.

Pj.