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
