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

["Kévin Le Gouguec" <kevin.legouguec@gmail.com>]

João Távora <joaotavora@gmail.com> writes:

> A simple, readily verifiable fact remains.  M-x package-install RET
> eglot in Emacs 29 will bring you a older version than in Emacs 28.  If
> not today, tomorrow, eventually it will.  And that's just bad in my
> opinion.  And it will become worse.
>
> If, in your opinion, this is somehow a good or indifferent thing, we can
> stop the whole discussion right here.
>
> Again: if you think it's a _good thing_ that, in Emacs 29
>
>   (use-package eglot :ensure t) 
>
> or
>
>   (package-install 'eglot)
>
> or 
>
>   M-x package-install RET eglot
>
> produces an older version of Eglot than the very same form in Emacs 26,
> 27 and 28, please do say so ASAP.
>
> I was under the impression that you didn't prefer that, but I'm not sure
> anymore after reading your complex last paragraph.

If I may throw in my ¢2: in Emacs ≤28, users never had a choice between
a "installing the newest Eglot from GNU ELPA" and "requiring that Eglot
be available, possibly not the latest & greatest".  They could only
request the former.

It's anyone's guess which of those two things users who cargo-cult those
configuration lines would prefer, now that the question is up in the air
for Emacs 29.  FWIW, I'd lean toward the latter: IMHO, package-install,
resp. (use-package … :ensure t), merely suggest ensuring availability,
not proactively ugprading to the latest (unlike say "package-update").

So I wouldn't be shocked for package-install to be a no-op for :core
packages, the semantics being "make sure the package is present,
favoring any built-in version which presumably underwent lots of
validation & stability fixes on the release branch".

With that perspective, I don't think the change in behaviour users will
observe in Emacs 29 re. which version of Eglot they get with `M-x
package-install eglot' is necessarily "worse": it depends on how much
one values "a release branch's worth of stability fixes" vs "a
development branch's worth of new features".

(
  Although I can understand that, in the _specific_ context of an LSP
  client that is in active development & "competing" with a MELPA-only
  alternative, it is a bit of a bummer that M-x package-install 𝒫 will
  yield something that users might consider "inferior" feature-wise when
  𝒫=eglot.  A bit of a bummer, but not a deal-breaker IMO; as long as
  "M-x package-list U x" brings the latest & greatest, I still think
  package-install's behaviour change re. eglot in Emacs 29 is
  defensible.
)

(
  Sorry for butting in and adding more words to this lengthy discussion;
  just thought that hearing the perspective from one random user might
  help.  I must also confess that I might not have read the whole thing
  as attentively as I perhaps should have; the parallel subthread
  between Eli & Philip re. changing package-install or package-update
  makes me unsure what "U x" will actually do with eglot in Emacs 29, so
  my previous parenthesized digression might be moot.
)