Re: Calling (package-initialize) sooner during initialization

[Taylan Ulrich Bayırlı/Kammer]

Stefan Monnier <address@hidden> writes:

>> A user is likely to expect everything defined by a package to be
>> available during the execution of their init.el; the failure to meet
>> this expectation is why we get so many confused users asking for help,
>> receiving the answer "just put (package-initialize) at the top of your
>> .emacs".
>
> But the current code in Emacs's "master" solves this problem by adding
> "(package-initialize)" in the user's ~/.emacs.

I had not realized this is already implemented.

I generally feel uncomfortable about a tool automatically editing a file
that I assume to have control over, but maybe that's fine.

A concrete problem I can think of is when one has some settings for
package.el in their init file, then Emacs ends up putting
(package-initialize) at the top, when it should be after the package
related settings.  Is this not a problem?

Other than that, it simply feels wrong to "solve" the problem with a
trick like this as if initializing packages after init.el is the normal
case, when the normal case is that init.el assumes presence of installed
packages.  That is, behavior is broken by default, but gets auto-fixed
with a trick like this.  WTF?  It might be simple to implement, but
conceptually it's rather confusing.

One might argue it doesn't get conceptually any simpler because there's
simply one init.el and it's agnostic towards package.el, but that's both
wrong (packages are automatically initialized after loading init.el if
it hasn't been done there) and a sign of the package system being
crudely bolted on top of existing machinery.  That's stinky engineering.

I hope I'm not coming off as religious.

>> If nobody sees any disadvantages, and nobody beats me to it, I might
>> start working on implementing the solution that separates pre-package
>> configuration from normal configuration, including Customize.
>
> I don't really know what solution you're referring to.  But so far
> I haven't seen any solution proposed that's really better than
> what we already have.

Splitting pre-package-initialization configuration from normal
configuration.  (Here "configuration" refers to the user's init file as
well as Customize.)  Making Emacs init look like:

    1. pre-package-init.el, & Customize settings in it (or loading
       `package-custom-file')
       
    2. package-initialize
    
    3. init.el, & Customize settings in it (or loading `custom-file')

This entails extending Customize functionality to offer something like a
:pre-package-init flag which tells the system to write customization for
the relevant defcustom into `package-custom-file' (falling back to
pre-package-init.el) instead of `custom-file' (falling back to init.el).

Yes, this is a more involved solution, but it brings some structure into
Emacs initialization with regard to the role of the package system, and
its interaction with Customize.


By the way, I just noticed our support for default.el and site-start.el.
I guess said separation of pre- and post-package-init configuration
would be applied to those as well if we were being idealistic, though I
think it should be fine to leave that be and only load default.el and
site-start.el after package initialization.  Or can anyone think of
valid use-cases for a site admin to hook in some Elisp before users'
package initialization?

Taylan