unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: zimoun <zimon.toutoune@gmail.com>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 54375@debbugs.gnu.org, Charles <charles.b.jackson@protonmail.com>,
	Maxime Devos <maximedevos@telenet.be>
Subject: [bug#54375] Mutable guix shell environments
Date: Tue, 15 Mar 2022 10:49:52 +0100	[thread overview]
Message-ID: <CAJ3okZ0g5PcEmaMRJd6dubMaTXXNXGdY19LeZebzHRmEcOvxKg@mail.gmail.com> (raw)
In-Reply-To: <87pmmop490.fsf_-_@gnu.org>

Hi,

On Mon, 14 Mar 2022 at 23:19, Ludovic Courtès <ludo@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




  reply	other threads:[~2022-03-15 10:50 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-13 18:21 [bug#54375] Mutable guix shell environments Charles via Guix-patches via
2022-03-13 19:51 ` Liliana Marie Prikler
2022-03-13 23:38   ` Charles via Guix-patches via
2022-03-14  5:19     ` Liliana Marie Prikler
2022-03-14  6:24       ` Charles via Guix-patches via
2022-03-14 17:43 ` Maxime Devos
2022-03-14 17:54 ` Maxime Devos
2022-03-14 19:41   ` Charles via Guix-patches via
2022-03-14 22:18   ` Ludovic Courtès
2022-03-15  9:49     ` zimoun [this message]
2022-03-15 23:52       ` Charles via Guix-patches via

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAJ3okZ0g5PcEmaMRJd6dubMaTXXNXGdY19LeZebzHRmEcOvxKg@mail.gmail.com \
    --to=zimon.toutoune@gmail.com \
    --cc=54375@debbugs.gnu.org \
    --cc=charles.b.jackson@protonmail.com \
    --cc=ludo@gnu.org \
    --cc=maximedevos@telenet.be \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).