Hi Mark! Mark H Weaver writes: > It doesn't remove them, but it overwrites them, thus losing the > information of what the previous environment was. Now, it's true that > for *most* of those environment variables, the previous value is a > suffix of the new value, but that's not always the case. One notable > counter-example is GUIX_PROFILE itself, which is simply overwritten. > Others include GIT_EXEC_PATH and ASPELL_DICT_DIR. - ASPELL_DICT_DIR is broken: #29686. We should fix it anyways. - What's the use of GUIX_PROFILE once a profile is loaded? I believe it's only there for the user to know which was the last loaded profile. Which is a bit broken in my opinion: I believe GUIX_PROFILE should point to the default profile, but this is not possible when using multiple profiles. With my `guix-activate` proposal, GUIX_PROFILE would not have to be overridden. Although we could also fix this by modifying the etc/profile file so that they don't depend on GUIX_PROFILE being set to themselves (which is the actual bug here). - You are right about GIT_EXEC_PATH, any clue why it has to be overridden? > There's no way to change the environment variable in Emacs without > running Emacs lisp code, e.g. by running M-x setenv. Indeed, for Emacs `guix-activate` would run some Elisp code. It would essentially work for every program that can edit its own environment. > Note that I'm not passing judgement on the merits of your proposals, I'm > merely letting you know that they cannot be implemented as envisioned, > at least not if I understand correctly. With the shell/Emacs/etc. specialization we discussed, I believe it would be :) To clarify: what I'm proposing is a more universal, better encapsulated way to activate profiles. Currently we can do --8<---------------cut here---------------start------------->8--- GUIX_PROFILE=/path/to/profile ; . $GUIX_PROFILE/etc/profile --8<---------------cut here---------------end--------------->8--- which has some shortcomings: - It only works for Bourne-style shells. Activating profiles for different shells / programs require some work from the user; we should do this work upstream I believe. - It exposes too many implementation details. - It's too long ;) Cheers! -- Pierre Neidhardt https://ambrevar.xyz/