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

[Arthur Miller]

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

>>> (On a related note, I'm not sure that making `package-activate-all'
>>> disappear is TRT.  I think it is useful to keep that function.)
>> When you say "to keep that function" you mean to run it at startup, even
>> when quickstart is activated or you mean to keep it at all as
>> functionality in package.el?
>
> `package-activate-all` is not an internal function (e.g. it's
> documented in `etc/NEWS.27`) so we have to preserve it.
>
> It can be very useful also for users who want to have more control about
> which packages are activated when (e.g. activating packages before the
> end of `early-init.el` or from within `init.el`).
I have to say I am little bit unsure of how this works.

Maybe I missunderstand how it works; but can user activate packages
before the end of early-init.el if they don't require package.el?
Wouldn't it be contradictory to the idea of quickstart?

Docs says new file has to be generated every time activation of a
package is changed:

  "Precompute activation actions to speed up startup.
This requires the use of `package-quickstart-refresh' every time the
activations need to be changed, such as when `package-load-list' is
modified."

>> This does not do any functional change other but avoiding to load
>> package.el when quickstart is active.  If a user would really like to
>> have package.el loaded from the start time, than it is just to call
>> (package-initialize) in user init file?
>
> `package-initialize` is a thing of the past.  Nowadays users should
> never need to call it (that doesn't mean it's never useful: it's used
> internally in various `package.el` functions and there may still be
> cases where it's needed outside of `package.el` but these should be
> considered as bugs, IMO).
Ok; I didn't know. I just checked some interactive functions without
calling package-initialize in a fresh Emacs process and they work, so
it's super.

>>> Does your patch avoid loading package.el?
>> Yes. When package-quickstart.el exists in user-emacs-directory.
>> If that file does not exists then everything is loaded just as before,
>> and (package-activate-all) will be run as normally.
>
> Oh, indeed, that's another option I had not considered.
>
> I was thinking of arranging for `package.el` not to be loaded regardless
> of the use of `package-quickstart` (i.e. preload all of
> `package-activate-all`), but maybe you're right and the only case where
> it's worthwhile avoiding to load `package.el` is when we use
> `package-quickstart`.

I just hacked things with the least effort possible :-). This was the
smallest change I was able to come up with atm.

Are you sure it is worth the efforth? It would move things in two
different places, would need more care to work with later on.

I don't see why someone would not want to use quickstart? So as a
thought: why not make quickstart normal mode how package loading works?

We could move quickstart file into package archives directory, the
"elpa" dir in .emacs.d and when packages are installed instead of emitting
autoloads.el in every directory, we could append them into an autoloads.el
database, i.e. quickstart file.

That would need some extra care to remove and update those correctly
when a package is uninstalled and updated; but if we insert start and
end markers for each package in an elisp comment, it wouldn't be
difficult to implemented.

Alternatively just scratch the file and re-generate on every
update. Does not seem to take awfull lot of time to generate it, so it
would be even easier strategy.

Is that too much or could it work?