GNU bug report logs - #54375
Mutable guix shell environments

Previous Next

Full log

View this message in rfc822 format

From: zimoun <zimon.toutoune <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 54375 <at> debbugs.gnu.org, Charles <charles.b.jackson <at> protonmail.com>, Maxime Devos <maximedevos <at> telenet.be>
Subject: [bug#54375] Mutable guix shell environments
Date: Tue, 15 Mar 2022 10:49:52 +0100

Hi,

On Mon, 14 Mar 2022 at 23:19, Ludovic Courtès <ludo <at> gnu.org> wrote:

> 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.

While I understand the need of Charles's proposal, especially in
development or exploration, I am convinced that this "incremental
style" is the root of many unreproducible computational environments.
The "incremental style" is a quick and dirty approach for creating a
computational environment and because the discipline is wrong then it
lead more than often to hard-to-reproduce computational environment,
therefore Guix should not try to mimick, IMHO.  I agree with Liliana's
words: «Guix is functional by design and we should not compromise on
that.».  To me, it is as programmers being strongly used to imperative
style complaining about the paradigm shift of the functional style --
or vice-versa... I digress. :-)

To mitigate because we have to work and sadly need to have things done...

> One could do:
>
>   $ guix shell a
>   [env]$ guix shell b
>   [env]$ guix shell c

..somehow, it would ease if when requiring the package 'b', the
environment is "aware" of the search paths of the environment required
by the package 'a'.  For instance,

--8<---------------cut here---------------start------------->8---
$ guix shell man-db
[env]$ tree $MANPATH
/gnu/store/m3i9pga6rqfg342sajzww4gl8w51q6sz-profile/share/man
├── index.db ->
/gnu/store/pdh5nz4qkg5q243q5rgxkk1hnmaf1plq-manual-database/share/man/index.db
├── it -> /gnu/store/vg7g63qddkd8jxlhlm9j1wxxj8wnn2mx-man-db-2.9.4/share/man/it
├── man1 -> /gnu/store/vg7g63qddkd8jxlhlm9j1wxxj8wnn2mx-man-db-2.9.4/share/man/man1
├── man5 -> /gnu/store/vg7g63qddkd8jxlhlm9j1wxxj8wnn2mx-man-db-2.9.4/share/man/man5
└── man8 -> /gnu/store/vg7g63qddkd8jxlhlm9j1wxxj8wnn2mx-man-db-2.9.4/share/man/man8

4 directories, 1 file

[env]$ guix shell coreutils
[env]$ tree $MANPATH
/gnu/store/m3i9pga6rqfg342sajzww4gl8w51q6sz-profile/share/man
├── index.db ->
/gnu/store/pdh5nz4qkg5q243q5rgxkk1hnmaf1plq-manual-database/share/man/index.db
├── it -> /gnu/store/vg7g63qddkd8jxlhlm9j1wxxj8wnn2mx-man-db-2.9.4/share/man/it
├── man1 -> /gnu/store/vg7g63qddkd8jxlhlm9j1wxxj8wnn2mx-man-db-2.9.4/share/man/man1
├── man5 -> /gnu/store/vg7g63qddkd8jxlhlm9j1wxxj8wnn2mx-man-db-2.9.4/share/man/man5
└── man8 -> /gnu/store/vg7g63qddkd8jxlhlm9j1wxxj8wnn2mx-man-db-2.9.4/share/man/man8
--8<---------------cut here---------------end--------------->8---

Here, 'coreutils' is not "aware" of the parent 'man-db' and thus
MANPATH does not contains the expected 114 files.

--8<---------------cut here---------------start------------->8---
     $ guix shell coreutils man-db
[env]$ tree $MANPATH
[...]
4 directories, 114 files
--8<---------------cut here---------------end--------------->8---

Using an option, say '--transient', a new profile is created each time
but what this new profile contains would depends of the parent
profile.  Last, the manipulation of a "temporary" profile is done via
"guix shell" thus this "transient" profile should be manipulated via
"guix shell" and not "guix package" (or aliases as "guix install").
However, what could appear still annoying is the stack of environment:

  guix shell a
  guix shell b
  guix shell c

then remove the package 'a' from the environment requires to exit 2
environments and then re-create them.  Need more thoughts. :-)


Cheers,
simon

Previous Next

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