[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Stefan Monnier
Subject: Re: Summary and next steps for (package-initialize)
Date: Tue, 22 Aug 2017 23:15:28 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

>> > I think we should instead explore the possibility that
>> > package-initialize will be called only in startup.el.
>> I think this is unlikely to work well.

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.

> As I said, we should explore this in more detail, and have a detailed
> and agreed-upon list of reasons why it's not TRT.

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.

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.

> This is hard to interpret without knowing "where you sit".

The other alternative will involve comping up with a configuration
scheme that is declarative enough to be able to automatically call
package-initialize when needed.  So it will involve changing the way
~/.emacs is written.  This will take many years, and I don't think
anyboy has really started this journey,


reply via email to

[Prev in Thread] Current Thread [Next in Thread]