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

["Thompson, David" <dthompson2@worcester.edu>]

Hey Ludo,

First of all: Thanks for picking up where I left off all those years
ago.  You remember mailing list posts I wrote 4 years ago much better
than I do. ;)

On Sat, Oct 2, 2021 at 6:22 AM Ludovic Courtès <ludo@gnu.org> wrote:
>
> Hello Guix!
>
> Here comes ‘guix shell’, a proposed replacement for ‘guix environment’!
> ‘guix environment’ would stay around though, at least for some time,
> probably for a long time.
>
> The differences to ‘guix environment’ are:
>
>   1. ‘--ad-hoc’ is the default.
>
>        ‘guix shell hello’ ≍ ‘guix environment --ad-hoc hello’
>        ‘guix shell -D hello git’ ≍ ‘guix environment hello --ad-hoc git’
>
>   2. ‘guix shell’, without arguments, loads ‘guix.scm’ or ‘manifest.scm’
>      from the current directory or one of its ancestors.
>
>   3. ‘--load’/‘-l’ is not ‘-f’/‘--install-from-file’ for consistency with
>      ‘guix package’.
>
>   4. ‘guix shell’ without arguments maintains a cache, such that, the
>      second time you run it, it runs in ~0.1s (it does not even need to
>      connect to the daemon).
>
>      If you run ‘guix pull’ and run again ‘guix shell’, it recomputes
>      the environment, as is currently the case with ‘guix environment’.
>
> Here’s a summary of previous proposals:
>
>   - Dave Thompson: https://lists.gnu.org/archive/html/guix-devel/2017-08/msg00300.html
>     - [X] --ad-hoc is the default
>     - [X] caching
>     - [X] behavior with no arguments
>     - [ ] --load accepts <environment>
>     - [ ] Shepherd services
>     - [ ] 'guix environment --update' to explicitly update
>   - make --ad-hoc the default: https://issues.guix.gnu.org/38529
>     - [X] https://issues.guix.gnu.org/38529#17: proposal for a new subcommand
>           deprecation of ‘guix environment’
>
> I think <environment> records and Shepherd services could come later.
> As for ‘--update’, I prefer the behavior implemented here because it’s
> stateless and thus more predictable.
>
> Thoughts?  Are there other changes people would like to see?

A few thoughts:

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.

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.

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.

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?

Anyway, great work!  Back to lurking.

- Dave