[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#54375] Mutable guix shell environments
From: |
Ludovic Courtès |
Subject: |
[bug#54375] Mutable guix shell environments |
Date: |
Mon, 14 Mar 2022 23:18:35 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) |
Hi,
Maxime Devos <maximedevos@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’.