Re: wishlist: “repack” generations history of profile

[zimoun <zimon.toutoune@gmail.com>]

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