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

[Ludovic Courtès]

Hello!

"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?

> 2) One important use-case for tools like Bundler, npm, etc. is to
> exactly (within their limited ability to do so, of course) reproduce
> the environment for all developers working on the project.  With 'guix
> environment', and now with this proposed 'guix shell', the resulting
> development environment depends upon the version of Guix being used.
> So, to make 'guix shell' a true universal replacement for these
> language-specific tools, there should be a way to "lock" to a specific
> version of Guix.  Bundler has Gemfile.lock, npm has package-lock.json,
> etc.  Guix has good support for using older versions of Guix already,
> so it seems feasible.  I spend a non-trivial amount of time sorting
> out development environment issues for a couple dozen devs,
> so a tool that took most of the variables out of the equation would be
> really great.

This part is currently addressed by ‘guix describe -f channels’ (to pin
the Guix revision) and ‘guix time-machine’ (to spin up a specific
revision).  The other tools are totally unaware of revisions and
channels.

As it stands, developers would use the pinned version by running:

  guix time-machine --commit=XYZ -- shell

or:

  guix time-machine -C channels.scm -- shell

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

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.

> 3) I haven't looked at the patches to see if it has already been
> implemented, but when running 'guix shell' with no arguments, I think
> the search for the manifest file should follow the established
> conventions of Git, Bundler, etc. and search not only the current
> directory, but the parent directory and so on until it finds it or
> gets to / and gives up. This will make the tool much more usable when
> working inside a subdirectory within a project.

It’s implemented (and controversial).

> Just some things to think about.  I just don't want to see Guix commit
> to an interface that slams the door on future improvement due to
> compatibility reasons.  I mean, what would you even name the next
> tool? guix... biome?

Good point.  :-)

Thanks,
Ludo’.