[bug#50960] [PATCH 00/10] Add 'guix shell' to subsume 'guix environment'

[zimoun]

Hi Ludo,

On Thu, 7 Oct 2021 at 11:27, Ludovic Courtès <ludo@gnu.org> wrote:
> "Thompson, David" <dthompson2@worcester.edu> skribis:
>
> > 1) I can't be the only one that thinks it's a pain to rebuild the
> > whole environment just because I updated the Guix client. It's
> > especially frustrating when there is a regression that breaks the
> > project, or the substitute servers are having a bad day.
>
> The way I see it, I update Guix precisely to get a newer environment.
> Otherwise, why would I update it for?

I think there is a kind of misunderstanding because one updates Guix
because of new project B but then rebuilds the whole environment for
project A.  And this can be unpleasant.

The solution is to use "guix time-machine -C channels.scm --
environment" but again this can be unpleasant because it builds a lot
of things; although before one runs "guix environment".

Well, you should tell me that the solution is to create a profile.
However, I often use "guix environment" with the options --pure or
--container, and a profile cannot, IIUC.


> Perhaps ‘guix time-machine’, too, could automatically detect
> ‘channels.scm’.

Well, I am not convince it helps for readibility.  At the end, it would read:

  guix time-machine -- shell

but then to know what this command does exactly, one should open the
manual check the "guix time-machine" part, check the presence of the
'channels.scm' file, then read the "guix shell" part, then check if if
is 'manifests.scm' or 'guix.scm'.  Maybe, it is just habits, but I
find much simpler:

  guix time-machine -C channels -- shell -m manifest.scm
  guix time-machine -C channels -- shell -f guix.scm

where I just have at the command-line type "guix time-machine --help"
or "guix shell --help" to remember the options and if I do not know
what manifest is, then I go to the manual.

With completion, it is not longer to type.  "Explicit is better than
implicit" as a good Zen says!


> The temptation to add revision data to tools that don’t otherwise deal
> with it is real; I think it’s better kept separate though, because
> fundamentally, each revision lives in its own world.

I agree.


All the best,
simon