Re: Friendly discussion about (package-initialize)

[Stefan Monnier <monnier@iro.umontreal.ca>]

> The problem is that even if I don't use package.el, there may be some
> stuff left in ~/.emacs.d/elpa from previous times.

Then don't do that: we want to make it as straightforward as possible for
users to install&use packages from GNU ELPA, so automatic activation of
those packages that were installed is a prerequisite.

Inevitably there will be situations where this design goal will clash
with the end-user who wants to use something else and will want to
explicitly "disable" package.el.

>> We could change tactic: only call package--ensure-init-file when the
>> user installs a package.
> I don't think I would enjoy this either.

Do you mean that it would be worse, or that it would be better but still
not good enough?  Based on your earlier message, I'm pretty sure I will
not come up with a solution which you really like, so I'm only aiming to
get "better" rather than "good enough".

> Would you consider it an acceptable solution to pop up a window or
> display a message telling the user that they should put
> `package-initialize' in their init-file, provided that we didn't have
> it get called during init?

No, I think this will reduce your annoyance level a tiny bit, along with
that of a handful of other users (all of whom likely already know
several different ways to work around the current annoyance), while
significantly increasing the annoyance level of many more new users who
just want to get on with their business without having to know anything
about how package.el works.

IOW, a bad trade-off.

>     The problem is that if there is an error while loading the
>     init-file, then the call to `package-initialize' still gets
>     inserted, if init hadn't gotten to the point where the actual call
>     to `package-initialize' was supposed to happen.

But if the call is only inserted during package-install it means that
you'd need both:
- use package-install
- in a session where your init failed to call package-initialize
for the problem to show up.  This combination seems a lot less likely
than the current one.

Another thing we could consider is to drop the automatic call to
package-initialize in lisp/startup.el (again, based on the idea that
this has now been made unnecessary by package--ensure-init-file).

>     Besides, often one wants to test something in a plain Emacs but
>     not in 'emacs -Q'. In this case, the call to `package-initialize'
>     will still get inserted.

I don't know what is a "plain Emacs but not in `emacs -Q`".  When I need
something like that I do something like

    mv ~/.emacs ~/tmp/
    <runemacs>
    mv ~/tmp/.emacs ~/

so any edits to ~/.emacs during the test will be happily thrown away
without bothering anyone.

So it seems like you're thinking of another kind of "plain Emacs but not
in `emacs -Q`".

>> I'd be very interested to work with maintainers of other package
>> managers to see how we could make them better interoperate (e.g.
>> make it possible to install with one tool, but activate&config with
>> another).
> Sounds like a great idea. However, do note that this will only be
> useful for package managers that use the package.el format (e.g.
> Quelpa, Cask, Pallet) and not for others (e.g. el-get, Borg,
> straight.el).

Part of "make them interoperate" may involve changing the formats
accepted&|used by the various tools, indeed (on-disk, on-the-server,
...).


        Stefan