bug#19390: 25.0.50; `package-activate' is too slow

[Artur Malabarba <bruce.connor.am@gmail.com>]

2014-12-16 14:53 GMT-02:00 Dmitry Gutov <dgutov@yandex.ru>:
> That aside, it's too bad not the whole of discussion leading to this
> implementation is public.

The discussion started here:
http://lists.gnu.org/archive/html/emacs-devel/2014-10/msg00567.html
Oddly enough, I can't find the end of it. =/
I'll be glad to explain any of the considerations.

> Have the following alternative implementation options been considered?
> Since we only actually want to reload when upgrading, or reinstalling
> packages, maybe some key logic can move into `package-delete'.

Besides the points I mention below, there's one edge case where this
could be a problem. Built-in packages can be upgraded too, and they
can't be deleted.

> For instance:
>
> 1. Instead of scanning through the whole load-history when activating a
> package, we could have a list of paths that belonged to packages that we
> uninstalled during the current session. It would be collected in
> `package-delete', and it would certainly be empty at startup.

The way it's done right now, package-delete is called after
package-install during upgrades, so that would need to change in order
for this implementation to work.
I would rather ask on the devel-list before making a change like this
(I don't know if there's a particular reason behind the original
choice), but other than that, that sounds like a good solution.

> 2. Instead of saving paths, remove elements from the `features' list
> when a package is deleted. Then when a dependency of this package is
> installed (or even autoloaded [0]), it would load the new files, because
> they're not in features.

Again, this relies on us deleting before installing, but I prefer you
first idea. Removing elements from `features' could have unintended
consequences. We're pretending the package isn't loaded even though it
is (all its functions and variables are bound).

>
> [0] IIUC, the current approach doesn't cover this situation.

The current approach does cover autoloads. The autoloads file of a
package is always `load'ed when a package is activated (which always
happens when a package is installed, even after an upgrade). Calling
`load' on a file which contains a new definition for an already
defined autoload (which is what happens on upgrades) redefines the
autoload to the new definition.