GNU bug report logs - #54375
Mutable guix shell environments

Previous Next

Full log

View this message in rfc822 format

From: Ludovic Courtès <ludo <at> gnu.org>
To: Maxime Devos <maximedevos <at> telenet.be>
Cc: 54375 <at> debbugs.gnu.org, Charles <charles.b.jackson <at> protonmail.com>
Subject: [bug#54375] Mutable guix shell environments
Date: Mon, 14 Mar 2022 23:18:35 +0100

Hi,

Maxime Devos <maximedevos <at> telenet.be> skribis:

> Charles via Guix-patches via schreef op zo 13-03-2022 om 18:21 [+0000]:
>> sample useage:
>> $ cd project
>> $ guix package --manifest=manifest.scm --profile=.guix-profile
>> $ guix shell # --profile=.guix-profile is implicit
>
> Alternative suggestion, which IMHO fits the non-persistent naturre of
> "guix shell" better:
>
> $ cd project
> $ guix shell --allow-temporary-modifications # fails on read-only file systems

Or ‘--transient’.

> $ echo $GUIX_ENVIRONMENT
> # a temporary (mutable) profile was created
>> $HOME/.cache/.../profile
> # install things in the $GUIX_ENVIRONMENT profile
> $ guix install foo bar ... 
>
> As noted by lilyp, this won't work in all situations due to search path
> issues.  These could be resolved by always setting a few search paths
> (PATH, EMACSLOADPATH, GUILE_LOAD_PATH, INFOPATH, ...) (even in not currently
> present in the profile!), at cost of having to make them ‘magical’ in some
> sense, which ludo does not seem to like IIUC.  (This could also be done
> for ~/.guix-profile)

I like this approach.

Charles’ proposal reminds me of ‘module’, a venerable “environment
management” tool widely used in high-performance computing (HPC):

  http://modules.sourceforge.net/

That command allows for an incremental style like Charles proposes:

  module load gcc      # adds GCC to $PATH
  module load libgc    # adds libgc to $C_INCLUDE_PATH
  module unload libgc  # removes libgc from $C_INCLUDE_PATH

For this to work though, ‘module’ is actually a shell function: that
lets it adjust environment variables here and now.

Anyway, I digress…

I thought about this other approach:

  1. ‘guix shell’ always builds a new profile, as it already does.

  2. When ‘GUIX_ENVIRONMENT’ is defined, it computes search paths as a
     combination of the new profile and that pointed to by
     $GUIX_ENVIRONMENT.

  3. It spawns a new shell, like it already does.

Thus, instead of doing upfront:

  guix shell a b c

One could do:

  $ guix shell a
  [env]$ guix shell b
  [env]$ guix shell c

It is more accurate but less flexible than what you propose though,
because only child processes of the nested shells would see the
“changes”.  So maybe not a good idea, after all.

Hmm, need more thought…

Thanks,
Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.