Maybe we can Maybe we can divide those environment variables into two types: 1. Needed directly by human. For example the *PATH* environment, we use it to start whatever program from the shell. 2. Environment variables only needed by programs. For examples, the *PYTHONPATH*, or in this case *GI_TYPELIB_PATH*.
For _type 2_, we can try to wrap every program with a simple script, and propagate all the needed environment variables from its dependencies to that wrapping script. This should eliminate the need to put any of those environment variables into ~/.guix-profile/etc/profile, guaranteeing the safety of these variables. But this method won't solve all the problems. For examples *XDG_DATA_DIRS* will be classified as one of variables that needed by human because we need to use it to find GUI programs with GUI shell, and it's also needed by some programs (a script in this case): > This sounds similar to the following bug: > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26202 > To mitigate the problem in above link, which is the problem introduced by _type 1_ variables, maybe we can treat these environment variables differently. When guix is updating it to a new value due to change of profile, it should explicitly append the original value to the upgraded definition (explicitly means writing it down in expanded form, like "/home/fis/.bin", not $HOME/.bin or $VARIABLE_NAME). In the above bug, there is no way guix can define the *XDG_DATA_DIRS* earlier than the distro. (You have to run the distro then install guix, right?). It's not perfect, but it seems to work. I don't have any better idea for now. Does anybody know what kind of approaches are employed by Flatpak and Snap?