Hi, Ricardo Wurmus <[email protected]> writes:
> Dr. Arne Babenhauserheide <[email protected]> writes: > >> Carlo Zancanaro <[email protected]> writes: >>> One may argue that the system is functioning correctly, and this is an >>> unfortunate consequence of the way that Guix works. I would still >>> consider the faulty behaviour a bug - even if it is a result of >>> intentional decisions made in Guix's design. Running evince (i.e. >>> /usr/bin/evince) is failing because of an environment variable that >>> Guix's wrapper sets for emacs. That environment variable is propagated >>> to child processes (as environment variables are), and in this >>> instance that causes the child process to misbehave. This is a bug >>> caused by Guix's wrapping of emacs. >> >> In practical terms: You would expect Guix to rename the environment >> variable and also patch all guix-installed programs so that they use the >> renamed variable without affecting any non-Guix-Program? > > Yes. > > I agree that the current behaviour is a whole class of bugs that exists > because of confusion between non-Guix binaries and Guix binaries, such > as binary plugins loaded indiscriminately from locations in environment > variables. > > It is a difficult but, in my opinion, necessary project, to prefix all > these variables and to patch packages to use the prefixed variables for > augmentation, while also making sense of the unprefixed variables > (e.g. setting PYTHONPATH to make more Python modules available without > having the program use PYTHONPATH by itself). I have been thinking the same thing. It'd make sense to prevent unwanted interactions between Guix and a foreign distribution by prefixing all the environment variables used by Guix by GUIX_ and patching the software in Guix to honor those (along with their usual non-prefixed version). For example, we'd use GUIX_EMACSLOADPATH instead of EMACSLOADPATH. +1. Maxim
