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

[Drew Adams]

> > 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 the autoloads, though, right? Not like `load' or `require'.

I'm not sure what you mean, or which part of what I wrote you are
referring to.

My point was that for the "old" system there are two actions or kinds
of opt-in, before a library is "activated": (1) put the code in your
`load-path' and (2) load it.

Just putting a library in your `load-path' does not load it.

If a library has autoloads, and if those are processed, and if the
user then (at some point) triggers an autoloaded function etc., then
the library is loaded.  So there are actually 3 steps there.

Does `package-initialize' only process autoloads and not also load
a package?  I guess so.  And I guess that was your point/question.

> > 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."
> 
> I'm confused. We load their autoloads from loaddefs.el, don't we? Does
> package-initialize do more?

Maybe not.  It's a good point.

So maybe `package-initialize' is more analogous to functions such as
`update-directory-autoloads' and `update-file-autoloads'.

That does modify much of what I've said.  If "activating the package
system" means just processing the autoloads for packages that have
been "installed", so that it is like doing `update-directory-autoloads'
in each part of `load-path', then I guess I don't have a problem with
such automatic "activation".

(There remains, apparently, the question of how/when/where Emacs or
a user should invoke `package-initialize'.)