|Subject:||Re: Calling (package-initialize) sooner during initialization|
|Date:||Mon, 13 Apr 2015 23:52:17 +0100|
On Apr 13, 2015 12:22 AM, "Stefan Monnier" <address@hidden> wrote:
> > 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.
I'm fine with this solution too (magnums or rackets), but I wouldn't mind hearing the opinion of people who will be forced to do that.
> 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
IIUC, There's another situation where this will come up. If a mass package upgrade fails for some reason, there will be lots of old package directories hanging around in the elpa subdir.
So we can't just blindly load all those directories, we'll need to actually parse the packages contained in all of them, version sort them into something like package-alist, and load only the appropriate ones.
|[Prev in Thread]||Current Thread||[Next in Thread]|