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

[Mark Oteiza <mvoteiza@udel.edu>]

On 25/09/17 at 10:16pm, Radon Rosborough wrote:
> > I haven't seen one place where the problem_s_ involved have been
> > clearly articulated
> 
> 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?

I meant more explicitly--each of these use cases should be documented
with examples.  While the manual in its current state does explain
things, it can be better.

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

The only documentation I see is in NEWS and the manual, which is where
the old documentation was.

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

At the cost of users who customize package.el and don't need another
init file.

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

The current situation should never have happened.

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

Except for users who who don't need garbage dumped into their init file
and for users who change their package archives or the list of activated
packages in their init.el without the need of a package-initialize form
because they read the docs.

Apparently changing those custom variables is an edge case.
https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00209.html

> and
> this patch *maintains* that behavior.

which is why it gets a -1 from me.

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

An improvement from package--ensure-init-file is great, but that's still
more breakage than prior to package--ensure-init-file.

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

Emacs itself doesn't work OOTB for most people.  That it's customizable
in Elisp is a feature.