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

[Drew Adams]

> > If the rationale for the decision was only that you want to treat
> > package.el as a core part of Emacs rather than as an extension
> > then that's a bad rationale. You don't need to turn something on
> > just because it is a core part of Emacs.
> 
> I don't really understand what this argument is about.  The call to
> package-initialize does nothing at all, unless you installed some
> packages with package.el.  So it is still an opt-in feature, because
> the user must decide to install packages for it to do anything.

Deciding to "install" a package is somewhat analogous to putting
a library in your `load-path'.  That doesn't mean it gets loaded.
Activating a package (`package-initialize') is somewhat analogous
to loading a library.

Just because a user has installed a package, it doesn't follow
that s?he wants to always and immediately initialize that package
for each Emacs session.

Your comment is similar to saying that (require 'foo nil t) does
nothing if you have not put foo.el in your `load-path', so it
wouldn't hurt to automatically load everything that Emacs can
find in your `load-path'.  Just by putting something in `load-path'
you have opted in.

To that I say no, and Emacs has always said no.  "Installing" a
library does not imply that you also want to load/activate it.
We separate the two actions on purpose - two levels of opt-in for
a library.  And we have the same two levels for packages, IIUC.

A user might have many libraries in her `load-path', without ever
loading some of them in a given Emacs session.  A user might have
many packages installed, without wanting to activate some of them
in a given session.

Radon said that the rationale for activating the package system
automatically was that "we want to treat package.el as a core part
of Emacs rather than an extension."

My reply to that was to point out that being part of the core does
not imply activating.  I said that "lots of things are a core part
of Emacs and not extensions, but we don't necessarily turn them on
eagerly and by default."

Just because something is available by default in Emacs, i.e.,
without having to "install" it, does not mean that it is (or should
be) automatically loaded/activated.

Automatic loading/activation at the outset, just because something
is available, has not, in the past, been the behavior of "core" Emacs.
Core stuff is made available and easy to activate (and yes, some
small core set of the core is activated by default), but much of what
Emacs makes available to you by default is not activated by default.

Radon was saying, I think, that for the package system Emacs dev has
decided differently: it has decided that if you have installed a
package then you want it activated in all your Emacs sessions (except
emacs -Q).  He said, I think, that this was decided because opt-in
activation was too confusing for some users.

But he also said that it was decided because installed packages were
to be handled the way Emacs core is handled.  It was to that statement
that I replied as above: all of Emacs core is not activated by default.
Much of it is just made available, for a user to turn on (opt in).