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

[João Távora]

On Fri, Apr 14, 2023 at 8:18 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: João Távora <joaotavora@gmail.com>
> > Date: Fri, 14 Apr 2023 20:03:31 +0100
> > Cc: monnier@iro.umontreal.ca, rpluim@gmail.com, 62720@debbugs.gnu.org,
> >       larsi@gnus.org, philipk@posteo.net
> >
> > > > OK, but who does this and why, in your opinion?  And who has
> > > > `(package-install seq)` in their config and why?  And won't they get
> > > > the same updated 'seq' "accidentally" if they install anything else
> > > > that depends on newer seq, which is likely a lot of non-core
> > > > packages and likely to grow?
> > >
> > > I don't know.  But we did have core packages that were also on ELPA
> > > before Emacs 29, and people did get along with that.  So much so that
> > > I don't recall any complaints about this, definitely not complaints
> > > that claimed package.el is as badly broken as you seem to represent.
> >
> > I think it's simply and clearly because there weren't any non-core
> > packages that migrated to core before.  Were there?  Certainly
> > none with as fast a release cycle like Eglot's.
>
> You are missing the point.  My point is that users of all those other
> core packages are used to the current situation, where package-install
> doesn't update the built-ins.  They have workflows based on that.
> Those are the workflows that I don't want to risk breaking.

The only workflows that traverse this use case I can think of:

1. they routinely invoke a useless M-x package-install RET seq RET
, it prints "already installed" and they breathe a daily sigh of relief.

2. they have `(package-install 'seq)` somewhere in their init file
which runs daily and does nothing.

> Once the discussion with Philip runs to its completion, we _will_ have
> in Emacs 29.1 a way of upgrading built-ins, only not by default, but
> by an explicit user request.  Maybe this is not ideal, but we don't
> have time to find out what is ideal for all those involved, and this
> partial solution allows to get the job done without risking to break
> anyone's workflow.  So this is a good compromise, given the time and
> the constraints, at least from my POV.

There is already this way, that was never in question.  Package menu,
M-: or anything else, it's not _that_ hard.  But it's a shame that
the canonical use-package recipe for Eglot (or for use-package itself)
it will break.

Looking at the patches, it seems, from my POV, that using a prefix
argument and an extra customization option is much, much more
complicated than a simple whitelist or blacklist that the user
needn't ever see.

> > I _am_ realizing that, and even if I think the risks are minuscule,
> > I'm providing solutions that mitigate them.  And -- responsibly, I
> > think -- pointing to the fact that the risk surface is much larger
> > than you may think it is.
> I respectfully disagree with your assessment of the risks.  And
> eventually, it is my responsibility to do this job, so my assessment
> of that is what counts more.  I've heard all of your arguments (and
> also those of others), and considered all of them, and I still don't
> think the risk is high enough to justify the potentially-breaking
> changes that you propose, not on the release branch, not this late
> into the release cycle.

And even though I also disagree, equally respectfully, with your
assessment of the risks, and still I'm providing a solution that
eliminates them totally.

> > I will work and prepare that patch if you promise to at least
> > look at the code, follow the logic with me and consider the
> > patch for backporting if it's as safe as relying on a simple
> > `(if (memq package package-safely-upgradeable-builtins) ...)`
>
> Backporting can be considered for Emacs 29.2, not before that.
> Hopefully, by that time we will also have more data points regarding
> the various uses of this, in particular with Eglot, so that our
> decisions will be more informed.

OK.  Fair enough. If there's half a chance for 29.2 I guess I can work on
it.  Not today though.

João