GNU bug report logs -
#62720
29.0.60; Not easy at all to upgrade :core packages like Eglot
Previous Next
Reported by: João Távora <joaotavora <at> gmail.com>
Date: Fri, 7 Apr 2023 22:11:01 UTC
Severity: normal
Found in version 29.0.60
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
Message #706 received at 62720 <at> debbugs.gnu.org (full text, mbox):
On Sat, Apr 22, 2023 at 12:39 PM Dmitry Gutov <dmitry <at> gutov.dev> wrote:
>
> But the difference from Emacs 28 is indeed unfortunate, no argument there.
>
> Or if the new option stays around, I guess you could be recommending
> they customize it first?
No idea yet. I'm leaning eglot-update as it guaranteedly the most
consistent. That or straight.el or elpaca.el. Or no recommendation
whatsoever.
I just got my first bug report about a user where I can't tell
the version of Eglot being used but which is consistent with an
older version being used, perhaps unknowingly. This is, of course,
not unheard of, so let's see.
> We might as well switch to the "update all the cores!" model later, but
> hopefully by that time we have a good CI setup that tests the
> compatibility of all core packages with all Emacs versions they are
> supposed to support.
Right, that makes sense. If it helps, Eglot's CI has been doing that
for year now. It tests Eglot -- and its up-to-date dependencies --
in Emacs 26, 27 and 28. It's not very complex to set up.
> Do you prefer that package-install-upgrade-built-in (together with the
> behavior of package-install it enables) stays around?
No, my opinion is that I find this user unfriendly, and of course
even more so with the default value. I've already answered this
early on in the thread.
Creating customization points as a "cure" for haphazard design is
not a good practice. It's like there are two package managers
in Emacs. The package menu and the package-install. The
"upgrade :core" cat has always been out of the bag in the
first one fully, and in the second almost fully. And then
there's the third "package manager", i.e. use-package's specific
package-install behaviour. And nwo there is package-update which
is almost a newborn, but is already inexplicably broken. Putting
more customization variables into the mix is just adding variations
to a very crowded field, more questions to ask, more
fear-uncertainty-doubt.
The "update all cores" is frankly the safest model IMO. Of course,
I understand that others disagree -- and I even see their well.
So knowing emacs-devel, I don't have any illusions.
But I suspect they see this "update all cores" idea as some kind of
gargantuan jump from what is in Emacs 28, when in reality it's not
(again, because dependencies). And I also tend to think they
disagree because they haven't been working with this and with users
for as long as I have (and you have), so from afar it seems dangerous.
João
This bug report was last modified 2 years and 17 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.