> I think I'm not a big fan of your proposal because the only problem I
> see with the status quo is that a call to package-initialize in the
> init file is required at all.
Thank you for this explanation. It is really helpful, as it helps me
see why we have been talking at cross purposes.
> I think I don't see package.el as one out of many, but rather as a
> core component of Emacs. Given this, I'm inclined to be more
> tolerant of exceptions made just for that package.
This helps too. It made me realize that package.el really is core to
Emacs, which I previously failed to see just because I don't really
like package.el as a package manager.
> I'd be fine, for example, with saving package.el's configuration in
> a separate file that gets loaded early.
In light of what I've said above, I would be fine with this too.
Specifically, if we:
* removed all traces of `package--ensure-init-file'
* moved the call to `package-initialize' from after loading the
init-file to before loading the init-file
* loaded an optional second init-file before `package-initialize'
* made absolutely sure that it's trivial to disable package.el
permanently and unconditionally by setting
`package-enable-at-startup' in this second init-file
then I would be perfectly happy and would not bother anyone about this
again. I do want to raise two possible points of concern, which I
personally am fine with but maybe other people aren't:
* doing this would instantly break the configuration of everyone who
customizes package.el or uses it in a nonstandard way -- can anyone
think of a way to maintain some backward compatibility so Drew can
keep his configuration working from Emacs 20 to Emacs 26? ;)
* you will get a bunch of bug reports from people trying and failing
to customize package.el in their normal init-file, I guarantee it --
but this could at least be minimized by inserting big flashy
warnings into the docstrings of all the relevant variables
> That file doesn't need to be a full-fledged ELisp file. It could be
> an alist of relevant keys and values, like a dir-local file.
Bad idea. In particular, this will make it impossible to customize
`package-load-list' so that packages are loaded from package.el by
default, but can be overridden from a local checkout, which is a
pattern I've seen very frequently in the wild.
Besides, if we're going to require it to be static, why not just say
you can only customize package.el via file-local variables in the
primary init-file? (I know, I know, at least you could line-wrap
things. But still.)
~~~
Drew, Stefan, Eli -- would you be comfortable with this alternative
proposal, to add a second init-file as I've outlined above? It would
make package.el "just work" in all cases, without requiring any change
to the user's init-file, as long as users read docstrings before
customizing `package-load-list' etc., and as long as we're prepared to
sacrifice a little backwards compatibility (although maybe we can be
smart about it and make the change pretty painless).
Angelo -- ... sorry :P
I still think that calling package-initialize in the
init-file is "the right thing" from an architecture and
modularity perspective, but having a second init-file may be
a more pragmatic solution.