[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot
From: |
Kévin Le Gouguec |
Subject: |
bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot |
Date: |
Sat, 15 Apr 2023 13:19:29 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
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.
)
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, (continued)
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, Eli Zaretskii, 2023/04/14
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, João Távora, 2023/04/14
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, Philip Kaludercic, 2023/04/14
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, João Távora, 2023/04/15
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, Philip Kaludercic, 2023/04/15
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, João Távora, 2023/04/15
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, Dmitry Gutov, 2023/04/15
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, Eli Zaretskii, 2023/04/15
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, João Távora, 2023/04/15
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, Eli Zaretskii, 2023/04/15
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot,
Kévin Le Gouguec <=
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, Dmitry Gutov, 2023/04/15
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, João Távora, 2023/04/15
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, Philip Kaludercic, 2023/04/15
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, Kévin Le Gouguec, 2023/04/15
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, João Távora, 2023/04/16
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, Dmitry Gutov, 2023/04/16
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, João Távora, 2023/04/16
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, Eli Zaretskii, 2023/04/16
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, Eli Zaretskii, 2023/04/16
- bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot, Dmitry Gutov, 2023/04/17