[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Reproducible environments
From: |
Pjotr Prins |
Subject: |
Re: Reproducible environments |
Date: |
Tue, 6 Oct 2015 20:59:08 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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.