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

[Radon Rosborough]

> On what ground was item 2. dismissed in previous discussions?

I've been arguing against it on the grounds that if one Emacs package
out of several thousand needs an extra init-file to work right, while
all the others don't, it's probably a sign of bad design on the part
of the one package. In other words, it seems like needless complexity.

And besides, if package.el gets its own init-file to make its job
easier, why not Org? And Gnus? And Dired? And EPG? And Flymake? It
would be chaos.

> The only disadvantage is that there is an extra init file now.

Well, consider the confusion when people put customization of
package.el in their init-file and it doesn't work. I feel like we
might be trading a bunch of user confusion over package customizations
not working for a bunch of user confusion over package.el
customizations not working. And I feel like "put package-initialize in
your init-file" is an easier-to-understand resolution than "put
customizations of this specific list of variables into a second
init-file".

> Could somebody please summarize why it's such a fundamental
> rule that there can only be one emacs init file?

There's no rule; just a strong precedent that's been followed for
several decades (AFAIK).