Re: Calling (package-initialize) sooner during initialization

[Artur Malabarba <bruce.connor.am@gmail.com>]

2015-04-18 19:04 GMT+01:00 Taylan Ulrich Bayırlı/Kammer
<taylanbayirli@gmail.com>:
> Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>
>> Maybe a solution is to simply make customize-set-variables lazier, so
>> that variables with a :require see their setting delayed to after
>> package-initialize was called.  Or else, have package-initialize be
>> called by customize-set-variables.  Or...
>
> I'm not sure if this isn't an orthogonal problem, but indeed as someone
> who doesn't use Customize I didn't think about it at all, and know
> little about it so excuses in advance for ignorance.

Yes.
It's not completely orthogonal, as the problems are related. But
things like "have package-initialize be called by
customize-set-variables" will not solve the problem, because the
problem goes beyond custom.el.

> How about Customize being "smart" and separating package-related
> configurations from other ones?  I don't know how hard it would be to
> implement

custom.el would have to make a new defcustom keyword availabe
(something like `:before-package'), and then package.el (and any other
packages that need this) would simply set that keyword.

> obviously package related
> customization should be applied before package-initialize, but all other
> customization should be applied after package-initialize, since it's a
> configuration system, meaning it should be one layer above the package
> system, going purely by intuition.
>
> So startup would look like:
>
>   1. pre-package-init.el
>   2. Package related customization.
>   3. package-initialize
>   4. init.el
>   5. All other customization.

I think "4. init.el + All other customization." would be more
accurate, as the two are currently loaded together (and separating
them, if we want to, is another discussion entirely).

> Would that work?

AFAICS, yes.
I'm not in love with the complexity of this solution. However, I do
believe it solves both problems (the custom.el issue and the general
package.el issue), and I believe there's no way to do that with a
simpler solution.

So, I guess I'm saying I'm ok with this if nobody has a better idea.