> To be clear: I do not use the package system
Yeah, neither do I. So we're on the same page here.
> This is partly because I don't use packages, in general.
Remind me to ask why, sometime.
> And it is mostly because I use multiple versions of Emacs and
> multiple configurations, for testing, and I don't want to be
> bothered with telling package.el what to do and not do each time I
> use Emacs.
I know for a fact that there are alternative package managers which
are designed for this sort of use case, unlike package.el.
> (I would in fact like that to be even easier than now. "Installing"
> packages and enabling them seems too monolithic, to me. It seems to
> assume that a given user has only one set of preferences, which s?he
> uses all the time.)
I doubt this will change soon, as it's a fundamental part of how
package.el works. But that's why we have alternative package managers.
> But in your proposal the first init file is apparently loaded after
> `package-initialize' is done.
The order is:
1. Load package.el init-file
2. Run package-initialize, unless package-enable-at-startup was un-set
in (1)
3. Load regular init-file
4. Nothing else is done afterwards, unlike currently
> So it sounds like users will have `package-initialize' inflicted on
> them unconditionally.
Wrong. You just (setq package-enable-at-startup nil) in the secondary
init-file, and are never bothered by package.el again. This is much
better than the current situation, where you still have to (setq
package-enable-at-startup nil), but furthermore you have to put an
advice on an internal package.el function in order to avoid
(package-initialize) from being inserted under some circumstances.