Hi Étienne,
I am very late to the party. :-)
Well, there is a discussion about “guix shell”, “profile” and “guix
time-machine”. Since these concepts can appear as first as alien, let
me try a quick summary of my understanding.
+ “guix shell“ creates a temporary profile;
+ “guix time-machine” creates a temporary revision.
For the plumbing details, both live under “~/.cache/guix/” and all is
managed automatically.
An example:
$ guix package -m manifest.smc -p /tmp/foo
$ GUIX_PROFILE="/tmp/foo"
$ . "$GUIX_PROFILE/etc/profile"
Instead,
$ guix shell -m manifest.scm
somehow does the same but the user does not manually manage the profile
and activate it. This profile is automatically and transparently
managed.
Now, you might run “guix pull”, so there is a chance that the next “guix
shell” will not build the same underlying profile. That’s where “guix
time-machine” comes in. :-)
You “freeze” one revision with “guix describe -f channels >
channels.scm” then run
guix time-machine -C channels.scm -- shell manifest.scm
It is costly the first run, then all is cached. Somehow, this command
could be seen as “conda env activate“ coupled to some lock stuff.
All that said, one thing to know: when is the cache cleaned up?
There is a ’last-expiry-cleanup’ that tracks and does the job.
Basically, you do not have to worry about this ~/.cache/guix/. All is
automatically managed.
When the user runs ‘guix gc’ or the sysadmin also ’guix gc’ then this
cache is cleaned up if it is too old.
Now the question is about what does it mean “too old”? Although “guix
time-machine -C channels.scm -- shell -m manifest.scm” will rebuild all
if required, it can be at the wrong moment. Therefore, for some very
specific environment that I want to protect from “guix gc”, I create a
profile for them. Note it is rare and thanks many improvements, it
becomes more and more useless.
Obviously, if “guix gc” is never run, the manual management of “profile”
is fully useless, IMHO.
Cheers,
simon
