GNU bug report logs - #79957
30.2; Feature request - Incorporate package upgrades started from other Emacs instances

Previous Next

To reply to this bug, email your comments to 79957 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jeremy Bryant <jb <at> jeremybryant.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.2; Feature request - Incorporate package upgrades started from
 other Emacs instances
Date: Sat, 06 Dec 2025 23:35:35 +0000

Here is a specific feature request that may benefit from a bug tracking number,
although it could be an emacs-devel wider discussion.

High-level description of Problem:
If you run multiple Emacsen it appears that package upgrades may not be
reflected in other instances.


Say you run two instances, Emacs #1 and Emacs #2, both using an ELPA
package called, say, PackageX.

From Emacs #1, upgrade PackageX v1 to PackageX v2.
Usually you can benefit from the new version.

From Emacs #2, still using PackageX v1, how to use PackageX v2 without restarting?
It seems that some of the package.el infrastructure invoked in the
upgrade on Emacs #1 would need to be called or implemented from Emacs #2



Is this possible in the design of the packaging infrastructure?
Is this documented and I've missed it?

Or is the recommended way for a different Emacs instance to restart?  In
which case is there some work that could be done to implement the above?

Message #8 received at 79957 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Jeremy Bryant <jb <at> jeremybryant.net>
Cc: Philip Kaludercic <philipk <at> posteo.net>, 79957 <at> debbugs.gnu.org
Subject: Re: bug#79957: 30.2; Feature request - Incorporate package upgrades
 started from other Emacs instances
Date: Sat, 06 Dec 2025 20:35:53 -0500

> Say you run two instances, Emacs #1 and Emacs #2, both using an ELPA
> package called, say, PackageX.
>
> From Emacs #1, upgrade PackageX v1 to PackageX v2.
> Usually you can benefit from the new version.
>
> From Emacs #2, still using PackageX v1, how to use PackageX v2 without restarting?
> It seems that some of the package.el infrastructure invoked in the
> upgrade on Emacs #1 would need to be called or implemented from Emacs #2
>
> Is this possible in the design of the packaging infrastructure?

AFAIK, this is "as possible as" the upgrade that's done in Emacs #1.
So, yes, it's definitely possible, but with the same caveats as apply to
the Emacs #1 where it will often work but not always 100%.

> Is this documented and I've missed it?

I don't think it's documented, no.

> Or is the recommended way for a different Emacs instance to restart?  In
> which case is there some work that could be done to implement the above?

IIRC the "best" way to do that would be probably look something like
a function `package-activate-refresh` which aims to behave like
`package-activate-all` but starting from a state where some packages
have already been activated (or even loaded).

So it would:

- Collect the set N of packages that should now be activated.
- Compare that set with the current set O.
- For all packages that are both in O and in N but not with the same
  version (i.e. upgrade or downgrade), use the code we used in Emacs #1
  to force-reload the new files to override the old ones we had
  already loaded.
- For the set that's in O but now in N, hmm... that's a tough one.
  Maybe we can try `unload-feature` (tho I'm not sure if that works for
  package-quickstart now that I think about it).
- For the set that's in N but not in O, that's easy, we just activate them.

Note: such a function would be useful not only for the situation you
describe but also after changing config vars like
`package-directory-list` or `package-load-list`.

Note²: I'm not sure how to find the version of the packages in O, tho
maybe we don't actually need that, we instead need to find the
directories (in `load-path`) corresponding to the packages in O.
Not sure how to do that either, mind you, but some heuristic might go
a long way.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.