Re: Can I easily install GNU Emacs 27.1.50 via Guix?

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hi,

Ricardo Wurmus <rekado@elephly.net> writes:

> Dr. Arne Babenhauserheide <arne_bab@web.de> writes:
>
>> Carlo Zancanaro <carlo@zancanaro.id.au> 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