Re: [PATCH] Fixing package-initialize, adding early init file

[Mark Oteiza]

Radon Rosborough <address@hidden> writes:

>> This seems like a lot of changes that add new complications to the
>> startup of Emacs. Since I don't have time just now to review those
>> 150 messages, may I please ask for an executive summary to motivate
>> this change?
>
> You could read [1] for an explanation of what the problem is, and [2]
> for a list of the different ways people have proposed to solve it. But
> I will summarize again:
>
> * Currently, Emacs modifies the init-file to add (package-initialize)
>   to it when Emacs starts. This has many disadvantages [1] which I'm
>   not going to rehash here.
> * There are many proposals [2] on how to make package.el work out of
>   the box without requiring Emacs to modify the init-file. These all
>   have practical disadvantages, except for the proposal to add an
>   early init file, which solves the package.el problem

I haven't seen one place where the problem_s_ involved have
been clearly articulated, and still this patch does not improve any of
the places where user facing documentation was lacking in the first
place, and still requires the user to not only understand the forms that
must be in an init file, but now there is one more init file for the
user to manage.

The whole discussion and push for a "solution" is predicated on users
who can't be bothered to do things correctly _not_ having to do any
configuration.  This patch does not improve things in this regard, and
frankly I don't see that predicate as a good one for devising a
solution. At least it explains how we ended up with
package--ensure-init-file.

> with
>   essentially no disadvantages, and furthermore solves several other
>   problems at the same time (for example, people having no way to
>   disable the menu bar before it is initialized the first time).
>
> You can disagree with the above two points, but they were the outcome
> of the aforementioned 150 emails, and everybody seems to agree that
> this is the best approach. The only difficulty is actually making the
> relevant changes to startup.el, which are honestly pretty small in the
> grand scheme of things.

I suppose it's time I pipe up and indicate I vehemently oppose this
change.  AIUI it still breaks existing config of package-archives,
package-load-list, etc, which is something the incumbent solution also
breaks.  The only proposal I can support at this time is reverting the
incumbent solution, yet none from the maintainership is willing to
entertain the idea.

>> new complications
>
> The only new code is to load an additional init-file. It's definitely
> a new complication, but I don't think it's that bad.

I think adding another init file is unacceptable.