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

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

> I haven't seen one place where the problem_s_ involved have been
> clearly articulated

As for the problems with the current situation, check out [1] and also
the section for Proposal A in [2]. But again, I'll re-summarize:

* Emacs modifies the init-file automatically, without asking the user.
* If the user has set any variables related to package.el in their
  init-file, then Emacs will modify the init-file to do the wrong
  thing!

Unless by "problems involved" you meant more generally, for all the
different proposals? That is exactly what [2] was intended to cover;
could you clarify what exactly you would like articulated that hasn't
been already?

> this patch does not improve any of the places where user facing
> documentation was lacking in the first place

Actually, I'd disagree. I think this patch improves the situation, not
by adding more documentation, but by reducing complexity and therefore
reducing the need for additional documentation.

In particular, we no longer need to document the placement of
(package-initialize) in the init-file, as such placement is no longer
necessary.

> requires the user to not only understand the forms that must be in
> an init file

Could you clarify what you mean by this? This patch has the effect
that users can put package configuration right into their init-file,
or use Custom to achieve the same, without having to know anything
about the package system.

If on the other hand "forms" is referring to 'setq' forms that
customize the package system itself, then indeed, users must know to
put them into a different init-file. However, I'd argue that this
isn't much worse than the current situation, where users must know to
put them *before* (package-initialize), and they must also know that
Emacs will put (package-initialize) in the wrong place with regard to
these customizations.

> 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

Correct. The current behavior is that things work out of the box, and
this patch *maintains* that behavior. Since things already work out of
the box, I don't see how you expect this patch to somehow improve that
particular aspect any further.

What this patch accomplishes is eliminating the problems inherent in
automatic modification of the init-file, *without* losing the goal of
the package system working out of the box.

> 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 [...] and frankly I don't see that predicate as
> a good one for devising a solution.

The goal is that when someone uses M-x package-install to install a
package, and then they paste some Lisp code from the project's README
into their init-file, then it works as expected. I think this is
desirable behavior, and I think most everyone else thinks this is
desirable behavior as well. That's why the current solution was put in
in the first place, because people really wanted that use case to
"just work". This patch achieves that same goal in a better way.

> AIUI it still breaks existing config of package-archives,
> package-load-list, etc, which is something the incumbent solution
> also breaks.

Correct, but here is the important point: it will only do so *once*,
when people upgrade to Emacs 26. As opposed to the current solution,
which breaks existing config every time (package-initialize) is
inserted, which may happen many times for a given user. So this patch
is a definite improvement.

> 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.

That's because it would result in the built-in package manager not
working out of the box, which would be embarrassing from a UX
perspective. That's the whole *point* of having a built-in package
manager: that it works right away without additional setup.

> I think adding another init file is unacceptable.

Why? (Especially given that being able to run code before the first
graphical frame is initialized would be super useful for lots of
reasons, entirely separate from the package system.)

[1]: https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00154.html
[2]: https://lists.gnu.org/archive/html/emacs-devel/2017-09/msg00023.html