> Again? How about not being bothered the first time? It sounds like
> `package-initialize' is evaluated the first time, unconditionally.
This is wrong. `package-initialize' is called only once, in step (2).
This step happens before loading the primary init-file, but after
loading the secondary init-file. If you set
`package-enable-at-startup' to nil in the secondary init-file, then
`package-initialize' will never be evaluated under any circumstances.
> And it sounds like, even if I don't use the package system, I will
> have to edit a secondary init file (the first one read), just to
> tell package.el "Hands off!"
You will have to do that only once in the entire history of your
dotfiles. No longer is `package-initialize' called after loading the
primary init-file, so a single `setq' is all that is needed to
permanently disable package.el.
> And if I want to try a package in a particular Emacs session then I
> need to once again edit that first ("secondary") init file, to
> enable the package system. Is that right?
No, it's wrong. To try a package, all you have to do is run M-x
package-initialize. In fact, if it's a new package you are installing,
M-x package-install will suffice, as package.el is initialized
automatically when you try to use it.
> It's hard to believe this has to be so convoluted.
It seems very simple to me. The package manager is initialized before
reading the init-file, unless you tell it not to do that. And in any
case, you can initialize it later. The only nonstandard part of this
is that the code to disable automatic initialization goes in a
separate file.
> (But I understand that you are saying that what you propose is less
> convoluted than what we have now.)
Oh heck yes. Even I don't really understand the full ramifications of
the current system.
> It seems to me that use of package.el should be just like use of any
> other library. Users should explicitly opt in. But I understand that
> you've said that it has been decided to enable the package system by
> default for everyone, at the outset.
The rationale for this decision was that we want to treat package.el
as a core part of Emacs rather than as an extension. If you want to
debate that, then fine (I might join you), but let's take it as
granted for a moment. If package.el is a core part of Emacs, then we
expect all of its features to work by default. And we also expect
libraries installed using package.el to work similarly to libraries
that are shipped with Emacs. That's why it's enabled by default.
Note that I'm not really complaining about this decision, even though
I don't like package.el and never use it. It seems reasonable to me
for the built-in package manager to act like this, even if I don't use
said package manager.
> It doesn't matter, IMO, if 99% of the users want to opt in; it
> should still be opt-in.
It really depends on whether you view package.el as a core part of
Emacs or not. After all, the menu and tool bars are turned on by
default; VC is turned on by default (even though lots of people turn
it off and use Magit); why shouldn't the package manager be turned on
by default?
I think it's fine for stuff to be turned on by default as long as it's
easy to turn it off again and swap in something else:
(menu-bar-mode -1)
(tool-bar-mode -1)
(setq vc-handled-backends nil)
(setq package-enable-at-startup nil)