[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: wishlist: “repack” generations history of profile
From: |
zimoun |
Subject: |
Re: wishlist: “repack” generations history of profile |
Date: |
Sun, 05 Jun 2022 11:45:36 +0200 |
Hi,
On Sat, 04 Jun 2022 at 09:39, Giovanni Biscuolo <g@xelera.eu> wrote:
> IMHO all users must understand that for
> their projects (profiles) to be reproducible and versioned the /only/
> way is to keep channels.scm and manifests.scm in a VCS (i.e. git)
I agree. This practise is the target but as a matter of fact, we are
not there yet. From what I daily see, scientists are starting to
integrate Git in their workflow, they are also starting to provide how
they generate their computational environment, but some are slower than
others. ;-)
>> That’s why, something like “repack” is missing. As a user, I should be
>> able to do
>>
>> guix package --switch-generation=1
>>
>> whatever the sysadmin collects about the old generations and whatever I
>> saved using some external tools.
>
> ...except you wish to reproduce the project on another machine, or
> /gnu/store is lost or corrupted for some reason
On the same machine, by the same user. Consider that the project is 2
years long, you start to install some packages and run an analysis, 4
months later you receive other data and you analyse using an updated
version of tools, 2 months later you want to reanalyse all and you use
another updated version of tools… and you have some differences.
Therefore, you want to roll-back to the first generation and see… Bah
you cannot because it is many months old and the sysadmin runs “guix gc
-d 3m” to save some space.
Such roll-back should be possible – a full rebuild the profile though.
I mean, let GC as usual but also “repack“ the necessary information.
Then, if you wish to run on another machine, you can always run
’export-manifest’ and ’export-channels’ from this “repack”.
I agree that tracking channels.scm and manaifest.scm is the good
practise. And I am trying to promote this very hard. :-)
However, we are often saying: do not worry, you can always travel back
in time (implicitly assuming Guix have the information :-)). And this
assumption is often missed which leads to uncomfortable situations, not
to say maybe some scientists are sometime blaming sysadmin and/or Guix
promoter. :-)
Somehow my point is: The time scale of a project is often very different
to the time scale of GC on a machine. Most of the time, the old
generations are useless and it is fine to remove them. But for few rare
cases, they are necessary – and it is impossible to know in advance or
to know the range of time. These few exceptions do not justify to keep
all these old generations; it does not make sense because the
“environmental costs” (storage, electricity, etc.). Today, the only way
is a manual tracking when it could be nice to have a more automatic
feature; similarly as ’export-manifest’ and ’export-channels’, they are
not necessary per se because the good practise is track the files using
Git, but they are very handy in many situations. :-)
Cheers,
simon