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

[Drew Adams <drew.adams@oracle.com>]

> > > 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'.
> 
> So that's the flaw in your reasoning: these two are NOT analogous.  A
> user who installs a package using package.el does mean to use it.
> That's what package.el installation does, that's what it is for.
> 
> If one only wants to have the package somewhere on load-path, they
> shouldn't use package.el, but instead just download the files, or
> clone the Git repository, and then add the directory to load-path.
> 
> > That doesn't mean it gets loaded.
> 
> Actually, it does.

Does it load the files of the package, or just process its autoloads,
so that using an autoload function etc. then loads the package?

> > Activating a package (`package-initialize') is somewhat analogous
> > to loading a library.
> 
> No, it isn't.

How about analogous to processing autoload cookies?

> > 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.
> 
> Yes, it does mean exactly that.

Too bad, if so.  A user should, I think, be able to hit a key to
download a package and have it _available_ to be used, without
necessarily loading its files in each Emacs session.  S?he should
then be able to load it (whether explicitly or by using and
autoloaded function) or not.

> There are ways to disable an installed package after the installation,
> but the default is to make it available when Emacs starts.
> 
> So you have some very different use case in mind, not the one we are
> talking about here.