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

[zimoun]

Hi,

On Fri, 18 Dec 2020 at 20:36, Carlo Zancanaro <carlo@zancanaro.id.au> wrote:

> On Fri, Dec 18 2020, zimoun wrote:
>> Maybe I miss something and I have not dove into all the details 
>> so I could be totally wrong.  However, from my understanding, A 
>> is built against the shared library C1, and B is built against 
>> the shared library C2, and nothing says that C1 and C2 are 
>> compatible.
>
> This is true if they are in the same address space, but in this 
> case evince runs as a separate process. There's no reason it has 
> to load the same libraries as emacs, or have the same GTK_PATH 
> variable. You should be able to show this by replacing evince with 
> a script that unsets GTK_PATH before invoking the system evince. I 
> have attached such a wrapper, if you want to add it to your path 
> to check on a foreign distribution (it makes the print dialog in 
> evince work for me, even when I run evince from within Guix's 
> emacs).

Is your point that:

   guix environment --ad-hoc emacs coreutils diffutils --pure
   env > /tmp/env.xterm
   emacs -q -f shell
   (emacs) env > /tmp/env.emacs
   diff /tmp/env.xterm /tmp/env.emacs

--8<---------------cut here---------------start------------->8---
1a2,3
> TERMCAP=
> INSIDE_EMACS=27.1,comint
7a10
> COLUMNS=115
9c12,13
< TERM=xterm-256color
---
> TERM=dumb
> GTK_PATH=/gnu/store/v3rqcgz6chnmv2sg7lgf4s9kv2xyb5rl-gtk+-3.24.23/lib/gtk-3.0
11c15
< SHLVL=1
---
> SHLVL=2
14c18
< PS1=[env]\n\w/\n\u@\h$ 
---
> XDG_DATA_DIRS=/gnu/store/jqyb550ir6m374sd34qw5970lgj103xw-shared-mime-info-1.15/share:/gnu/store/rxg53s8xwc70lpbpp0bfsx89387ahclb-glib-2.62.6/share:/gnu/store/v3rqcgz6chnmv2sg7lgf4s9kv2xyb5rl-gtk+-3.24.23/share:/gnu/store/929jj5kcwg5c01ksdpml3r1nhlgz9k3b-emacs-27.1/share
--8<---------------cut here---------------end--------------->8---

so GTK_PATH and maybe XDG_DATA_DIRS should not be there?


However, on my machine running Guix on the top of Debian, I get:

--8<---------------cut here---------------start------------->8---
guix environment --ad-hoc emacs grep coreutils --pure
env | grep GTK_PATH
/usr/bin/evince # Works!

emacs -q -f shell
sh-5.0$ env | grep GTK_PATH
GTK_PATH=/gnu/store/v3rqcgz6chnmv2sg7lgf4s9kv2xyb5rl-gtk+-3.24.23/lib/gtk-3.0
sh-5.0$ /usr/bin/evince

(evince:21780): GLib-GIO-ERROR **: 11:24:25.706: No GSettings schemas are 
installed on the system
Trace/breakpoint trap
sh-5.0$ unset GTK_PATH
sh-5.0$ env | grep GTK_PATH
sh-5.0$ /usr/bin/evince

(evince:25064): GLib-GIO-ERROR **: 11:32:22.826: No GSettings schemas are 
installed on the system
Trace/breakpoint trap
--8<---------------cut here---------------end--------------->8---

So the story seems more complicated than GTK_PATH. :-)

> 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.

I have no opinion.  Even if usually, I prefer that by default the child
(M-x shell) inherits from parent.

>>> I run into a similar problem where my window manager 
>>> (awesomewm) sets LD_LIBRARY_PATH, which then propagates to 
>>> everything I run from my session. It's quite a pain. I thought 
>>> there was an open issue for this, but I can't seem to find it 
>>> at the moment.
>>
>> On foreign distro or Guix System?
>
> I am using Guix on a foreign distribution. I imagine a Guix system 
> would mask this bug because we wrap lots of programs (using 
> wrap-program or similar) so that they explicitly set the 
> environment variables they run with, but it may still be possible 
> to provoke it Guix built binaries. I haven't tried.

Thanks for the explanations.


All the best,
simon