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

[Radon Rosborough <radon.neon@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2181 bytes --]

> we're introducing a major user configuration change

Is it really that major to move the place that two options are
configured from one file to a different file? To me, this seems pretty
trivial.

> some shortcoming in Emacs internals

I think this assertion requires justification. It's not clear that
there is any shortcoming in Emacs internals. On the contrary, I would
say that the pattern of configuring a package manager, having it load
the packages, and then using the packages is exactly the right pattern
to use.

> the feature lookup API I proposed in the other letter

That proposal requires its own discussion before we decide if it's the
right way to go or not. Your argument is only valid if we decide that
we want this API, and we haven't decided that yet.

> And with the current state of packaging I think such API is almost
> inevitable.

Whether or not this statement is true will be determined by that
discussion.

> But with second init, people would still be stuck with those files,
> even when raison d'etre for them disappears.

"if" raison d'etre for them disappears. We don't know that yet.

> 20 years down the line

Five years ago, we had no package manager at all. And that's one heck
of a breaking change, compared to moving two `setq' declarations from
one file to another.

> you may need to explain to people "Oh, no, you don't need config.el,
> you needed it like 15 years ago, but not anymore"

Remember that the only people who are going to be using this secondary
init-file are advanced users who want to customize the process of
loading packages. IOW, 0.1% of Emacs users, and not the ones we should
be concerned about confusing.

                                ~~~~~

But you still haven't addressed the real problem, which is that when
Emacs inserts `package-initialize' into the init-file, it usually does
so incorrectly. Do you really think that we should adopt a solution
which objectively does the wrong thing just for the sake of
compatibility with a hypothetical new API whose implementation is
likely months or years in the future?

In my opinion, this issue is a blocker for your proposal. How are you
suggesting to deal with it?

[-- Attachment #2: Type: text/html, Size: 2990 bytes --]