Re: Summary and next steps for (package-initialize)

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden
> Date: Tue, 22 Aug 2017 23:15:28 -0400
> 
> Re-reading what you wrote, I realize that I wrongly interpreted "only in
> startup.el" to mean "after loading the .emacs", whereas My suggestion to
> "call package-initialize before reading ~/.emacs" would actually also
> imply that package-initialize is only called in startup.el.
> 
> So we're probably in agreement.

Yes, I think so.

> Calling it in startup.el means either calling it before or after loading
> ~/.emacs, AFAICT.
> 
> Calling it after ~/.emacs (like we currently do) is too late since it
> means that ~/.emacs can't use installed packages, and that several
> configurations can't be done in the usual way.
> 
> Calling it before ~/.emacs means that package-initialize is done before
> the user got a chance to configure package.el.  So we need'd to provide
> some way to reproduce the behavior you can currently get by setting
> various package.el vars before calling package-initialize.  E.g. we
> could let a second call to package-initialize de-activate previously
> activated packages and activate previously not activated packages.

Would a ~/.emacs.d/.package-initialize.el file, to be read by
package-initialize before it does anything else, be a better
alternative for configurations that must be done before
package-initialize is called?

Or maybe you have some other alternative ideas for how to make this
happen?

> Packages bundled with Emacs are activated (long) before loading
> ~/.emacs, so calling package-initialize before ~/.emacs seems like the
> most natural behavior in that it makes ELPA packages behave similarly to
> bundled packages.
> 
> But then we need some way to deal with users setting
> package-directory-list or package-pinned-packages or package-user-dir
> after package-initialize was called.

Right, which is why I suggested to have a separate file for that.

Thanks.