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

[Radon Rosborough <radon.neon@gmail.com>]

> Thanks for putting this proposal together. Can you explain what
> advantages it holds over my previous proposal, which didn't require
> creating an init file if there was none, nor having an explicit
> package-initialize form?

Sure. I think your proposal would work in principle, but it seems like
an unnecessarily complicated way to solve a simple problem. No other
package in Emacs requires this level of infrastructure just to
customize and use it: why does package.el need it? (I've asked this
question before, comparing package.el to other packages and package
managers, and have not yet received an answer as to why package.el has
to be so special.) That said, here are the concrete disadvantages I
see with your proposal:

* It is impossible to customize `package-load-list'. If
  `package-initialize' is called before loading the init-file, and
  then I call `package-set-load-list' in order to load only a subset
  of packages, it won't have any effect since all the packages were
  already loaded the first time `package-initialize' was called. Since
  `package-initialize' is called once, explicitly, in my proposal,
  there is no such problem.

* More generally, `package-initialize' will be called before my
  customizations of package.el. If I customize `package-user-dir',
  then I think I can reasonably expect that only packages in the new
  location, and not ones in ~/.emacs.d/elpa, will be activated. Not so
  with your proposal; packages in both locations will be activated.
  Again, this problem does not exist in my proposal since users simply
  do the obvious thing: put package.el customizations before calling
  (package-initialize).

* Every other variable in Emacs is customized by setting it to a
  value. It is confusing for package.el to be customized by adding a
  special dotfile to ~/.emacs.d. My proposal requires no such
  inconsistency and therefore does not violate the Principle of Least
  Surprise.

* I find it hard to believe that we won't see significant performance
  regressions with the current implementation of package.el. Thus your
  proposal can't be adopted until the implementation is fixed so that
  calling `package-initialize' multiple times takes negligible extra
  time. OTOH, my proposal can be adopted right now.

The first two points are the real problems here: fundamentally I think
it's a non-starter to call `package-initialize' before loading the
init-file. Unless, of course, you introduce a new init-file that's
called before `package-initialize', and that's a whole new can of
worms.