[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Summary and next steps for (package-initialize)
From: |
Radon Rosborough |
Subject: |
Re: Summary and next steps for (package-initialize) |
Date: |
Mon, 21 Aug 2017 09:34:25 -0700 |
> > > 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.
>
> 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.
PROPOSITION: Calling `package-initialize' only in startup.el is
impossible without one of the following consequences:
1. It is impossible to customize `package-load-list' and
`package-user-dir'.
2. We must add a second init-file.
3. The user cannot add package customizations to their init-file
without using `after-init-hook'.
4. Packages are not activated automatically.
PROOF:
* Packages must be activated at some point, since otherwise
consequence (4) holds. This activation must happen either before
loading the init-file, during the init-file, or after loading the
init-file.
* Packages must be activated either before loading the init-file or
during the init-file, since otherwise consequence (3) holds.
* Packages cannot be activated during the init-file since this
violates the premise that `package-initialize' is called only in
startup.el.
* Therefore, packages must be activated before loading the
init-file.
* Even though packages are activated before loading the init-file,
it must still be possible for the user to customize
`package-load-list' and `package-user-dir' before the activation
takes place, since otherwise consequence (1) holds.
* The user cannot put such customization in a second init-file,
since otherwise consequence (2) holds.
* There is no way for `package-load-list' and `package-user-dir' to
be customized outside of an init-file. But we said such
customization was necessary.
* Reductio ad absurdum.
Can someone find a hole in this reasoning?
- Re: Summary and next steps for (package-initialize), (continued)
- Re: Summary and next steps for (package-initialize), Radon Rosborough, 2017/08/21
- Re: Summary and next steps for (package-initialize), Eli Zaretskii, 2017/08/21
- Re: Summary and next steps for (package-initialize), Radon Rosborough, 2017/08/22
- Re: Summary and next steps for (package-initialize), Clément Pit-Claudel, 2017/08/22
- Re: Summary and next steps for (package-initialize), Radon Rosborough, 2017/08/22
- Re: Summary and next steps for (package-initialize), Eli Zaretskii, 2017/08/22
- Re: Summary and next steps for (package-initialize), Radon Rosborough, 2017/08/22
- Re: Summary and next steps for (package-initialize), Clément Pit-Claudel, 2017/08/22
Re: Summary and next steps for (package-initialize), Stefan Monnier, 2017/08/21
- Re: Summary and next steps for (package-initialize), Eli Zaretskii, 2017/08/21
- Re: Summary and next steps for (package-initialize),
Radon Rosborough <=
- Re: Summary and next steps for (package-initialize), Clément Pit-Claudel, 2017/08/21
- Re: Summary and next steps for (package-initialize), Timur Aydin, 2017/08/22
- Re: Summary and next steps for (package-initialize), Radon Rosborough, 2017/08/22
- Re: Summary and next steps for (package-initialize), Clément Pit-Claudel, 2017/08/22
- Re: Summary and next steps for (package-initialize), Radon Rosborough, 2017/08/23
- Re: Summary and next steps for (package-initialize), Angelo Graziosi, 2017/08/23
- Re: Summary and next steps for (package-initialize), Radon Rosborough, 2017/08/23
RE: Summary and next steps for (package-initialize), Drew Adams, 2017/08/23
Re: Summary and next steps for (package-initialize), Radon Rosborough, 2017/08/23
RE: Summary and next steps for (package-initialize), Drew Adams, 2017/08/23