bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot

[João Távora]

On Sat, Apr 22, 2023 at 12:39 PM Dmitry Gutov <dmitry@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