emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Stability of core packages (was: Not easy at all to upgrade :core pa


From: Dmitry Gutov
Subject: Re: Stability of core packages (was: Not easy at all to upgrade :core packages like Eglot)
Date: Thu, 20 Apr 2023 01:06:10 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0

On 19/04/2023 23:57, João Távora wrote:
On Wed, Apr 19, 2023 at 9:50 PM Dmitry Gutov<dmitry@gutov.dev>  wrote:

So... are you sure that (use-package 'eglot :ensure t) upgrades/upgraded
the package?

  From what I'm reading in use-package-ensure-elpa, all 'package-install'
calls are wrapped in

    (unless (package-installed-p package)
      ...

That seems to mean that, as long as the package is installed already
(whether by being bundled, or because of a previous manual
installation), it shouldn't get upgraded when this form is executed.
That's true.  Exactly the same as package-install. It will not
reinstall over another one.

OK then, I think have to re-evaluate my position on this. Previously, I guess, I made some hasty conclusions from how the discussion went on without refreshing the exact details about package.el and use-package (the latter I never knew to begin with). Apologies.

Eli, let me know if we should take this back to the bug tracker instead.

But that doesn't change anything.  In Emacs 26/27/28 from scratch
package-install and use-package_will_  rev up Eglot to whatever is the
newest version.  In Emacs 29 it won't.

I think one of the conclusions to be made here is that even if (package-install 'eglot) now installs the newest version of Eglot in Emacs 29,

  (use-package 'eglot :ensure t)

still won't do that in Emacs 29 because (package-installed-p 'eglot) returns t still. So the commit 580d8278c5f48 doesn't help with your "most common upgrade method" cited below, if they rely on use-package instead of calling 'package-install' directly.

The patch I +1'd here https://debbugs.gnu.org/62720#467 wouldn't help with (use-package 'eglot :ensure t) either, IIUC.

But it would help in case the user put (package-install 'eglot) inside their init script, or if the CI script contains that. But the CI scripts could be fixed anyway (there must be a lot fewer of them out there than there are user installations).

Next: 'package-install' isn't supposed to install a new version when some version is already installed. The docstring says so, and I just tried this out: had older 'vertico' installed (with a newer one available in the repo), evaluated (package-install 'vertico), got back the message "already installed".

Do we want to change the semantics of 'package-install' just so the (minor) fraction of users who call this function directly will get Eglot upgraded when starting over from an empty config with Emacs 29? And/or change (package-installed-p 'eglot) to return nil when the appropriate user option is set? I'm not sure that's wise, certainly not the latter.

In fact deleting Eglot and restarting Emacs the config run again is what
I suppose the most common upgrade method (since there is no
package-update in Emacs 28).

I've never considered this particular scenario, but as explained above, it's still not "fixed" by either of the proposed approaches. Not entirely, at least.

The most common upgrade method, though, is hopefully 'package-menu-mark-upgrades'. Or:

  M-x list-packages
  U
  x

And that one also doesn't work for Eglot and other builtin packages. Unlike 'package-install', this behavior is not obviously correct, although it's "always been like this" so we're probably not going to change what it does by default at this point in time.

Another function which is supposed to upgrade packages in 'M-x package-update' (why aren't people commenting on bug#62750? the naming's gonna drive me crazy). This one is obviously incorrect because upgrades exist for Eglot, and yet it doesn't suggest any.

So I would suggest to focus on functions that don't work as intended. Namely:

- Add a user option for the list of builtin packages which would be upgraded automatically by 'package-menu-mark-upgrades' and 'M-x package-upgrade-all' (nee package-update-all). Maybe make it nil by default, or maybe add 'eglot' to it. I don't have a strong opinion.

- Fix 'M-x package-upgrade' (nee package-update) to suggest Eglot as one of the options and actually perform the upgrade. That shouldn't require changes to 'package-install' because, as we already know, the user can already install a newer version of Eglot using the 'list-packages' menu (and picking the exact version manually). That execution path is going to go through 'package-install' as well, so it must be suitable already.

- Revert 580d8278c5f48 because it creates odd semantics (upgrading certain packages that are already installed but not others) and it doesn't solve the issue with (use-package 'eglot :ensure t) anyway. We could keep it, but seems like a half-measure that didn't make anyone happy anyway. OTOH, it could minimize the rewrites of CI scripts.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]