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

[Radon Rosborough]

> You are unfairly challenging me with stuff I know very little about
> and therefore might make suggestions that are laughable.

I'm sorry. That wasn't my intention at all. I fully expect anyone else
to jump in and point out flaws in my reasoning, or to propose
alternative solutions. I'm not trying to suggest that because you made
the suggestion, you also have to have all the answers.

The only reason I'm attacking the proposal of only calling
`package-initialize' in startup.el is that I believe it's not only
difficult but fundamentally impossible to find any solution. I
outlined the reasons for that in my other email:

    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: [...]

And if somebody finds a flaw in that reasoning, then I'm all ears. But
otherwise, it seems futile to try to find a solution in this
direction.

> That being said, one possibility is to have a function in package.el
> scan the user init file for the definition of package-load-list, and
> process that line before loading the packages.

I really don't want to sound rude, but... *please* no. That would be a
horrible hack. It will fail in so many different circumstances:
package-load-list set in a different file, package-load-list set
dynamically, package-load-list set in an unconventional way,
package-load-list set by a macro, etc. etc. etc.

Emacs Lisp is Turing-complete. It is futile for Emacs to try to
understand it. In particular, Rice's theorem [1] says that all
nontrivial behavioral properties of Turing-complete code (such as
whether the user's init-file sets `package-load-list' or not) are
formally undecidable. So this approach is doomed to failure from the
very start.

[In fact, whether the user's init-file calls `package-initialize' is
also formally undecidable, so it will always be impossible to prevent
duplicate calls from being inserted on occasion...]

[1]: https://en.wikipedia.org/wiki/Rice%27s_theorem