bug#47458: Terrible UX upgrading Emacs in Guix

[Leo Prikler]

Am Sonntag, den 28.03.2021, 22:02 -0400 schrieb Mark H Weaver:
> I just updated my Guix system, which included the Emacs update from
> 27.1
> to 27.2.  After "guix package -m mhw-manifest.scm" finished running
> (which takes a long time for me, since I don't use substitutes), and
> before I even noticed that it had finished, my existing Emacs session
> started misbehaving badly.
> 
> It failed to even open a plain text file in fundamental mode (a .drv
> file) with an inscrutible error about 'arrayp'.  I tried to enable
> the
> debugger with M-x toggle-debug-on-error, but then I started getting
> errors about 'debug' not found.  (I neglected to record the exact
> messages).
As you are probably aware by now, this is a result of parts of your
EMACSLOADPATH being deleted.  I don't think there's a good solution to
this, but you could (as part of your early init file) resolve the
symlinks in it, so that it behaves deterministically until it is
garbage collected?

> [...]
> 
> Eventually, I realized what the problem was:
> 
> (1) My existing emacs session started failing because
>     ~/.guix-profile/share/emacs/27.1 had disappeared out from under
> it.
> 
> (2) My newly launched emacs sessions were failing because my
>     EMACSLOADPATH variable was still set to its old value, pointing
> at
>     /home/mhw/.guix-profile/share/emacs/27.1/lisp, which no longer
>     existed.
> 
> I'm not sure why I've never run into this problem before.  I'm also
> not
> sure what can be done to make this better, but if anyone has ideas,
> that
> would be good.  If a 7+ year Guix veteran developer gets bitten badly
> by
> this, I doubt that less experienced users will be impressed.
Remember the snippet, that tells you you might want to recompute your
environment variables at the end of `guix package'?  Well, this is just
that.  I've already made it a habit to close Emacs at that point (and
you probably have as well), but as you said, you didn't even notice the
update succeed, so that's what lead to the confusion.

In a similar manner, if I see an Emacs version upgrade at the start of
the transaction, I already know to prepare for a little environment
variable dance to get it to start correctly.  I think there has been an
idea to update environment variables in GNOME Shell directly, for
instance, but
a. we're lacking the technology to do so at the moment (e.g. guile-
dbus)
b. it's not clear, that Guix itself should do such a thing rather than
relying on the user to e.g. code up a oneshot shepherd service 

Regards,
Leo