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

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

From: Jeremy Bryant <jb <at> jeremybryant.net>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
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: Thu, 01 Jan 2026 12:31:45 +0000

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> 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:

Thanks Stefan for these ideas to implement the work.


There is a related feature request, which I am putting into this bug
request for ease of tracking.

It appears that updating packages in one instance of Emacs generally deletes the
previous files of the previous version of the packages.  Whilst this is
good for an update, it also confuses separate Emacs instances with an
older load-path.
Would there be a way to make it possible to have staggered versions of
packages concurrently?  I've read up on the Emacs and Elisp manuals
and it is not apparent.


One of my underlying motivations is that running multiple Emacs
instances enables some parallelism and effectively using multiple CPU
cores for parallel Lisp interpreters.
I think in practice it is easier to reconcile mismatches in package
versions, than in evolving Emacs to handle more parallelism within the
same Lisp interpreter.

Message #14 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: Thu, 01 Jan 2026 16:55:11 -0500

> It appears that updating packages in one instance of Emacs generally deletes the
> previous files of the previous version of the packages.  Whilst this is
> good for an update, it also confuses separate Emacs instances with an
> older load-path.

Good point, indeed, thanks.

> Would there be a way to make it possible to have staggered versions of
> packages concurrently?  I've read up on the Emacs and Elisp manuals
> and it is not apparent.

`package.el` was designed so as to support the case where multiple
versions of a package are installed: after collecting the set of all
installed packages, it picks which ones to activate, which includes
selecting which version of each package to activate (one cannot
activate two versions of the same package in the same Emacs process).

So, indeed we could keep the old package around and mark it for later
deletion instead (the precise definition of "later" left as an exercise
for the reader).


        Stefan

Previous Next

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