Re: Calling (package-initialize) sooner during initialization

[Taylan Ulrich Bayırlı/Kammer]

Stefan Monnier <address@hidden> writes:

> I think all those discussions are missing the point.
> If we want to improve the system to the point of considering adding new
> init files, then we should try and fix other problems at the same time.
>
> So here's one of the larger problems:
>
> How can we make the system work such that the user can:
> - Use customize to set package-user-dir, package-pinned-packages, etc...
> - Use customize to configure a variable which has a :require which loads
>   a file that's only available after calling package-initialize.
> The first requires package-initialize to be called late, the second
> requires package-initialize to be called early.
>
> 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.

How about Customize being "smart" and separating package-related
configurations from other ones?  I don't know how hard it would be to
implement, but it feels like the right design; 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.

Would that work?

Taylan