Replication question

Replication question

[Mauritz Stenek]

Hi all,

Suppose you have these packages in your environment:

    A@old
    B
    C

where `A` is pinned to the `old` version, which is not in the 
latest channel versions -- as per `guix describe`; the latest 
versions of both `B` and `C`, however, are in the latest channel 
versions but *not* in the channel versions where `A@old` is 
defined.

How, then, is this environment replicable without some hacky 
gymnasitcs?

What am I missing?

-- 
Mauritz Stenek <mstenek@disroot.org>

Re: Replication question

[Felix Lechner via]

Hi Mauritz,

On Tue, Apr 16 2024, Mauritz Stenek wrote:

> How, then, is this environment replicable [...] ?

Soon after switching to Guix System, I also adopted Guix Home.  Together
both more or less ensure a reproducible enviroment.  In your use case, I
believe only the packages are reproducible (such as the executables) but
not the entire environment.

As a Guix noobie, I don't understand all of the intricacies so it would
be prudent to wait for other answers before you draw conclusions.

Thanks for using GNU Guix!

Kind regards
Felix

Re: Replication question

[Richard Sent]

Hi Mauritz

Mauritz Stenek <mstenek@disroot.org> writes:

> Suppose you have these packages in your environment:
>
>    A@old
>    B
>    C
>
> where `A` is pinned to the `old` version, which is not in the latest
> channel versions -- as per `guix describe`; the latest versions of
> both `B` and `C`, however, are in the latest channel versions but
> *not* in the channel versions where `A@old` is defined.
>
> How, then, is this environment replicable without some hacky
> gymnasitcs?
>
> What am I missing?

Your hunch is corect. Without knowing the Guix commit that the
environment/profile was built with, you would not be able to reproduce
the profile exactly.

There's two options I know of:

1. Guix time-machine. e.g.
guix time-machine --commit=XXX -- package -m manifest.scm

     a. This will create a profile containing the exact packages at that
     moment in time, including A@old.

     b. All packages will be at whatever version the corresponding
     Scheme package variable is at for that commit. See (info "(guix)
     Invoking guix time-machine"). Probably not the best idea to use
     long term.

2. Inferiors. This provides a mechanism for mixing and matching A@old
from commit XXX with packages B and C from commit YYY. See (info "(guix)
Inferiors").

    a. To my knowledge this won't replace dependencies for B or C if
    they depend on A@old. B and C would use the "primary" channel's A.
    You probably could modify B and C to replace A with A@old though.

As you saw, A@old doesn't have any fancy logic for "go back to the most
recent Guix commit that has A@old". It's just a convenient way to
specify which version of package A to install when multiple are
packaged.

-- 
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.

Re: Replication question

[pelzflorian (Florian Pelz)]

Hello Richard; yours is a good answer.  Let me add:

Richard Sent <richard@freakingpenguin.com> writes:
> 1. Guix time-machine. e.g.
> guix time-machine --commit=XXX -- package -m manifest.scm
>
>      a. This will create a profile containing the exact packages at that
>      moment in time, including A@old.
>
>      b. All packages will be at whatever version the corresponding
>      Scheme package variable is at for that commit. See (info "(guix)
>      Invoking guix time-machine"). Probably not the best idea to use
>      long term.

Note that “guix time-machine … -- install” or “guix time-machine … --
build” can be used for individual packages.  So repeated time-machine to
each package’s commit can reproduce the environment (have not tested it,
but should be true).

guix time-machine can also take a channel description file instead
of a commit, if we are talking about other channels.

Also to comment on Mauritz’ question, the @ syntax of guile@2.2.7 has
nothing to do with reproducibility.  Everybody understood correctly that
by A@old, A from an old Guix commit was your intended meaning; I want to
clarify this for future readers.

Regards,
Florian