Re: Calling (package-initialize) sooner during initialization

[Sebastian Wiesner]

2015-03-30 21:01 GMT+02:00 Artur Malabarba <address@hidden>:
> On the "Customizable modes..." thread I suggested we run
> (package-initialize) sooner than the way it's currently done. Right
> now, it's called after loading the init file. Which means any user who
> tries to customize an installed package by pasting some code into his
> init file will be confronted with errors.
> This happens A LOT.
>
> Stefan kindly explains why it can't just be done before loading the init file:
>> [...] the user may need/want to run some Elisp
>> code of his own choosing *before* package-initialize is called.
>> E.g. [...] set package-load-list and package-directory-list
>
> But I'm asking that we try a little harder to find a better solution.
> This package.el-induced "cannot find load file" error is the most
> predominant issue I see people run into in the wild. Some people file
> issues for this stuff on github (and waste developer time), others go
> to the relevant forums, and others (I can only imagine) probably just
> give up on configuring packages (or give up Emacs!) entirely.
>
> So I hope we can try to converge on an actual solution instead of just
> resigning to something that harms the majority of the users. I propose
> here a couple of suggestions which still preserve the use-case outline
> by Stefan, and I'm perfectly open to other ideas.
> Even if we can't find an ideal solution, try to keep in mind how
> absurdly unideal the current situation is.
>
> Option 1) Check if the file `~/.emacs,d/.package-delay-init' exists.
> If it does, just do it the way we currently do. If it doesn't exist,
> do package-initialize first and then load the init-file. This
> `.package-delay-init' file is not loaded, Emacs would only check if it
> exists.
>
> Option 2) Instead of us manually telling users to add
> `(package-initialize)' to their init-files, we have Emacs do that
> automatically. Similar to how `custom.el' adds a call to
> `custom-set-variables' the first time you save a variable; package.el
> could add a call to `package-initialize' the first time you install a
> package. This would be a one-time-thing (and would take some
> intelligent coding to prevent annoyiances).
>
> Thank you all,
> Artur
>

I probably underestimate the complexity of this issue, so please
forgive if I say anything stupid, but… isn't this much too
complicated?

For most defcustom's it doesn't actually matter whether they are set
before or after the corresponding feature is loaded, does it?  So
there's only a very specific class of defcustom's which is affected at
all:  Namely, modes enabled through customize.

For these specific defcustom's the corresponding feature must be
loaded immediately anyway, since we must have the mode function
available to actually enable the mode, right?

So we could just require that a mode that is supposed to be enabled
through customize also has a ':require' keyword for the corresponding
feature.

And for :require features the whole problem looks pretty simple to me:
 Try to load the feature on 'set-custom-variables'.  If it fails
remember the corresponding form somewhere (i.e. 'custom-delayed-vars'
or whatever), and just try again after 'package-initialize'.  If it
still fails, report an error.

That sounds like a simple and straight-forward approach that's not too
invasive or too magic.  Would that not work?