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

[Radon Rosborough]

> So I don't quite follow you there.

Let me clarify. I see the following spectrum in this debate:

    People who want package.el to be enabled by default in spite of
    the resulting UX problems (too much magic, automatic modification
    of init-file).

    ^
    | (a) Have Emacs write (package-initialize) into the existing
    |     init-file at startup.
    |
    | (b) Have Emacs create a template init-file with
    |     (package-initialize) at startup, if one doesn't exist
    |     already.
    |
    | (c) Don't create (package-initialize) calls anywhere, but still
    |     call package-initialize in startup.el.
    |
    | (d) Don't call (package-initialize) anywhere; the user must call
    |     it manually in their init-file.
    v

    People who want package.el to be disabled by default in spite of
    the resulting UX problems (package management system doesn't work
    out of the box).

You and I are both at point (d). However, this is a rather extreme
position, so I am not arguing for point (d) or even point (c), but
rather point (b), because I view point (b) as an improvement over
point (a), which is the current situation.

Most people on this thread view any solution that doesn't involve
package.el working out of the box as a non-starter. That is why I am
not proposing such a solution. Instead, I am proposing a solution
which has much less potential for annoyance, while still having
package.el work out of the box.

Does this clear up the confusion?

> > I agree wholeheartedly with everything you have said. However, a
> > significant number of people on this list disagree,
>
> Hm.  I haven't read this thread very carefully.  But I also
> haven't gotten the impression that a significant number of
> people here have argued for generating init files.

You're right. I meant that you're arguing that Emacs shouldn't go
through contortions to make package.el work out of the box, and people
disagree with that. Meanwhile I'm just trying to make the contortions
less horrifying, as an immediate improvement to the current situation.

> So I can't say whether your proposal is better or is a compromise of
> some sort.

The part of my proposal that is relevant to you is the part where
Emacs doesn't try to write (package-initialize) into your init-file
automatically. Do you consider that an improvement?

> I don't like the idea of Emacs generating an init file if there is
> none OR of Emacs messing with an existing init file.

Same here. Unfortunately, the technical challenges in making
package.el work out of the box pretty much guarantee we have to do one
of these. Now, whether or not it's worth all this trouble to make
package.el work out of the box is another debate, but that's a much
harder debate than this one, which is why I'm not arguing it (at least
for now).

> I don't see your proposal as a "middle way", for users.

It's a middle way because creating a default init-file is less
intrusive than modifying an existing one, but still more intrusive
than doing nothing at all.

> Naively, I'd suggest that package.el should do what custom.el
> and bookmark.el and lots of other libraries do: Use a separate
> Lisp file for persisting info the library needs - a file whose
> name/location the user can set using an option.
>
> If that would mean that a user might need to load that file
> at an appropriate place in an init file, so be it.  The
> package system might well require some understanding of it
> before using it.

Again, agreed -- but emacs-devel does not want the user to have to
have any understanding of the package system before using it, so I'm
not making that argument.

(By the way, you're spot on with the separate Lisp file idea -- in
fact, package.el already does this, and the separate Lisp file
[directory] is ~/.emacs.d/elpa. This debate is over how to force users
to use package.el by activating it automatically. Again, while neither
of us thinks such a thing should be done, I think it's more realistic
to try to get it done in the least bad way possible, at least for
now.)

> FWIW, I am also not in favor of Customize writing to your init file.

Same.

> If it is difficult for users to find an appropriate place in
> their init file to load whatever state/settings file package.el
> might require, or to call `package-initialize' or whatever,
> then perhaps the package system could be improved to help with
> that somehow.

The solution here is improving the documentation of package.el, which
I've already suggested.

> I say "naively" because I know next to nothing about package.el, and
> I'm not trying to design the package system.

As someone who has in fact already written an Emacs package manager
from scratch (straight.el), I think all your points are spot on.
Thanks for your comments.