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

[João Távora]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: João Távora <joaotavora@gmail.com>
>> Date: Tue, 11 Apr 2023 21:08:32 +0100
>> Cc: "Philip K." <philipk@posteo.net>, Stefan Monnier 
>> <monnier@iro.umontreal.ca>, 62720@debbugs.gnu.org, 
>>      Lars Ingebrigtsen <larsi@gnus.org>
>> 
>>  > If this change can't go into emacs-29, I think it's better to add
>>  > an M-x eglot-update to eglot.el.
>> 
>>  That's the worst of all worlds.
>> 
>> Why? It's the safest option. Absolutely no package.el regression possible, 
>> and doesn't solve a problem
>> where you don't think I've exists.
>
> From your POV of the Eglot maintainer, it might make sense.  But from
> my POV, it doesn't: the problem here is general, and a solution is at
> hand that will give you what you want and also support all the other
> core packages.

Your solution doesn't "give me what I want".  If I add 'eglot-update' it
will work as a single command on every Emacs version from Emacs 26.3
onwards.  This new command you're proposing is for Emacs 29 only (and
will presumably be deprecated soon).

So "what I want(ed)" is for `M-x package-install RET eglot` to keep
working smoothly as it did up to here and forever onwards.  That's want
many package managers do (the "install" verb upgrades, or offers to
upgrade).  That not being possible, I had settled for a decent working
`M-x package-update RET eglot` instead.

So this is "what I want": smooth user experience with no new commands or
at least simple ones that don't require understanding emacs dev
concepts.

>>  What is the problem with the two possible solutions I suggested?
>> 
>> They are incongruent and not very user friendly IMO.
>
> The one which proposed a new command is a natural generalization of
> your eglot-update proposal, so I think it is as user-friendly as it
> gets.  As for congruency, Stefan just expressed his intuition about
> that, and I tend to agree with him: upgrades of core packages should
> indeed be handled by separate command(s) with somewhat different rules
> and perhaps also a different UI.

I think 'package-update-core-package' is just unfortunate, because the
regular user doesn't care what the heck is core, and can you blame her?

I can't stop you from adding it, of course.  Have you thought how it
should behave when the package is no longer a core package, i.e. has
already updated?  I.e. should 'package-update-core-package' update a
non-core package in certain situations?  If so, then we're inches away
from 'M-x package-update-any-package', which is just a fixed `M-x
package-update` as I proposed.  If not, then it's really quite strange
to have to run one command for one update and another command for the
next one.

I have to ask (though I can guess the answer): may I add 'eglot-update'
anyway to emacs-29 as a no-brainer shortcut in the meantime?

João