[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,
Stefan
- Re: Summary and next steps for (package-initialize), (continued)
- Re: Summary and next steps for (package-initialize), Radon Rosborough, 2017/08/24
- Re: Summary and next steps for (package-initialize), Eli Zaretskii, 2017/08/24
- RE: Summary and next steps for (package-initialize), Drew Adams, 2017/08/24
- Re: Summary and next steps for (package-initialize), Eli Zaretskii, 2017/08/24
- Re: Summary and next steps for (package-initialize), Radon Rosborough, 2017/08/24
- Re: Summary and next steps for (package-initialize), Radon Rosborough, 2017/08/24
- Re: Summary and next steps for (package-initialize),
Stefan Monnier <=
- Re: Summary and next steps for (package-initialize), Eli Zaretskii, 2017/08/24
- Re: Summary and next steps for (package-initialize), Stefan Monnier, 2017/08/24
- Re: Summary and next steps for (package-initialize), Eli Zaretskii, 2017/08/24
- Re: Summary and next steps for (package-initialize), Stefan Monnier, 2017/08/24
- Re: Summary and next steps for (package-initialize), Radon Rosborough, 2017/08/25
- Re: Summary and next steps for (package-initialize), Stefan Monnier, 2017/08/25
- Re: Summary and next steps for (package-initialize), Radon Rosborough, 2017/08/25
- Re: Summary and next steps for (package-initialize), Stefan Monnier, 2017/08/25
- Re: Summary and next steps for (package-initialize), Eli Zaretskii, 2017/08/25
- Re: Summary and next steps for (package-initialize), Stefan Monnier, 2017/08/25