Re: Calling (package-initialize) sooner during initialization

[Artur Malabarba]

On Apr 19, 2015 7:44 AM, "Philipp Stephani" <address@hidden> wrote:
>
>
>
> Taylan Ulrich Bayırlı/Kammer <address@hidden> schrieb am Sa., 18. Apr. 2015 um 20:04 Uhr:
>>
>> 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?
>
>
> I think that would be a good solution, although I'd modify it a bit:
>
> 1. Contents of init.el before applying customizations.

I'm afraid this step is already a problem. If these initial contents contain a (require 'some-package), the user will be given an error during initialization.

That's why Taylan's solution has an extra file. It's annoying, but necessary.

> 2. Applying customizations, either inline in init.el or by loading custom.el from init.el
>   2.a. Package related customization
>   2.b. package-initialize
>   2.c. All other customization
> 3. Rest of init.el
>
> That would be closer to the current behavior and eliminate the need for pre-package-init.el. 

It would be so close to the current behaviour that the problem wouldn't be solved. ;-)

The point here is that it needs to just work for the less knowledgeable user. We can't expect them to move their call to (require 'some-package) until after the custom.el snippet is loaded. Not to mention, they might not even have such a snippet.