Re: Calling (package-initialize) sooner during initialization

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

> To make myself a bit more clear, my proposal would mean adding these
> lines of code to startup.el just before the user init file is loaded:

> (dolist (dir (directory-files "~/.emacs.d/elpa" t "\\`[^.]"))
>   (when (file-directory-p dir)
>     (add-to-list 'load-path dir)
>     (dolist (autoload (directory-files dir t "-autoloads.el\\'"))
>       (load autoload nil t))))

OK, so it does a minimalist initialization, and the main direct downside
is that users can't directly "disable" packages, they have to move them
out of ~/.emacs.d/elpa instead.  That's not a bad tradeoff, indeed.

One more issue is for things like AUCTeX's TeX-modes, which is usually
set before auctex-autoloads.el is loaded, but indeed this already needs
to handle the case where the var is modified later (which is handled via
a :set function), so it's OK.

There are a few other issues, tho.  For example, the current code first
looks at all the installed packages and then only allocates the latest
version of each (modulo pinned versions).  So you can have several
versions of a given package installed (in different directories or not)
and package-initialize will know which one to initialize.

If we load all of ~/.emacs.d/elpa this won't handle all the corresponding
cases anymore.  More specifically, we'll end up initializing a package
in ~/.emacs.d/elpa even if a more recent version might be installed in
some other directory that will be provided later.

The main use case would be when the other directory is a system
directory, which we could handle by letting sysadmins change the
site-start.el file so as to (package-load-descriptors DIR).  This way,
they're not yet initialized, but package.el knows about it so it could
refrain from initializing a less recent package from ~/.emacs.d/elpa.


        Stefan