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

[Radon Rosborough]

> > > 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?