emacs-devel
[Top][All Lists]
Advanced

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

Re: bug#30854: 27.0.50; Speeding up package.el startup


From: Arthur Miller
Subject: Re: bug#30854: 27.0.50; Speeding up package.el startup
Date: Tue, 22 Dec 2020 00:15:06 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Stefan Monnier <monnier@iro.umontreal.ca> writes:

I think we are having multiple problems here. For the one there is
problem of quickstart: bringing autoloads into emacs and package paths
to load-path, for the second it is management of packages and users
deciding which packages to activate or not and third is discovering when
new packages are avialable (in site packages).

>> Sysadmin can install packages for many users to share them, users have
>> read priviledge, not write of course. Sysadmin would install/uninstall
>> packages and a user would need to read autoloads.el from that shared
>> system dirctory, and then maybe even from it's own?
>
> The users may have some of the packages installed in their
> ~/.emacs.d/elpa which take precedence over the versions installed by the
> sysadmin, and also their `package-load-list` may disable some of the
> sysadmin-installed packages.  So you can't have a single concatenated
> autoloads file for all the sysadmin-installed packages shared between
> all the users.

Could this strategy work: "site-autoloads.el" is used just to create
"user-autoloads.el" (I am just making up names, hope it is clear what I
mean with them) on first start. User can now disable/enable whichever
from sysadmin installed ones, as if they were present in users packages,
and regenerate autoloads.el as the docs describe. Emacs checks mtime of
site-autoloads.el and if it is changed it recreates new autoloads file
with respect to disabled packages.

I am not sure how that would be implemented, but it is probably not
impossible :-).

>
> So I think instead the package-quickstart file should come with a bit of
> extra freshness info, e.g. the `mtime` of all the directories in
> `package-directory-list` when it was created, so we can skip the
> quickstart and mark it "needs-refresh" when one of the directories has
> been modified (by (un)installing a package).

You mean to automate, so the user does not need to run
package-quickstart-refresh manually? It means Emacs would need to
iterate all the directories in site packages and user packages somewhere
at some time; probably in some idle timer function or do you have
something else in mind?

If sysadmin updated site packages then autoloads for the site would
change, so we can just check that file, if we use concatenated
autoloads.el, and we do want to use it for the speed? User autoloads
are fixed automatically at time of package management.

That would work with above idea to use site autoloads just to create
user autoloads and that is not so far away how package.el works
now (conceptually).

Checking mtime of site autoloads would address discoverability
of sysadmin installed packages, user inactivating package and
recreateing autoloads would address package management and we would stil
have one concatenated autoload file per user to quickstart emacs.

It is one idea; I am just trying to think of something efficient.



reply via email to

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