Re: Stability of core packages (was: Not easy at all to upgrade :core packages like Eglot)

["João Távora" <joaotavora@gmail.com>]

On Tue, Apr 18, 2023 at 1:56 PM Eli Zaretskii <eliz@gnu.org> wrote:

> without by side effect installing a newer and potentially less stable
> ElDoc.  (I also am surprised that change is a must for Eglot 1.15.)

It's not a "must".  Eglot can work without it.  The problem happens in
ElDoc and doesn't affect its interface.

But Eglot relies on ElDoc as a whole.  In general you can't expect
to have new features in Eglot without some advancing of the
infrastructure that Eglot depends on.  As highlighted in the manual
and elsewhere, Eglot is relatively thin glue between LSP abstractions
and Emacs abstractions.  It relies on this client-agnostic
infrastructure of ElDoc, Flymake, Xref, Project, Jsonrpc (and
soon others) and drives advances to that infrastructure too.
For example, I completely reworked Flymake in 2017 (in
backward-compatible fashion of course) precisely to support
Eglot's use case.  It supports many others of course, and there is
a healthy collection of non-Eglot Flymake clients.  Exactly the
same happened for ElDoc, and similar processes happen with Xref,
for example. These processes have been happening for a while now,
before Eglot was in core, and the model has proven its value IMO.

Anyway, this was just an introduction to what is Eglot's main
characteristic (and why it's sometimes called "minimal" and
well integrated with Emacs's existing features).

So there _isn't_ a way to partially upgrade a package and not its
dependencies.  And there _shouldn't_ ever be this way, for our
collective sanity.  And there's no good reason this should ever
exist.

> We should seriously ponder these aspects, and the sooner the better.

I don't actually think there is any actual problem present if
we all agree (as you seem to) with Dmitry's preposition that
"there shouldn't be a single set of criteria governing core
packages".  Then we can teach Emacs's upgrade mechanisms to
deal with each set differently, carefully examining the
requirements for each set.

I'd like you, if possible, to also respond (here, if you prefer) to the
points I raised in my own reply to Dmitry's message you're replying
to.  This is the message;:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62720#529

Thank you,
João