Re: Friendly discussion about (package-initialize)

[Radon Rosborough]

> You wrote lots and lots of lines of text just to complain about the
> addition of a single "(package-initialize)" in the user's ~/.emacs,
> which should do absolutely nothing in the case where the user
> doesn't use package.el (i.e. doesn't have anything inside
> ~/.emacs.d/elpa).

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. For example, let's
say that I am trying to write a comparison between my package manager
and package.el, so even though I don't usually use package.el, I use
it temporarily.

Then, after I'm done testing, I remove all traces of package.el from
my init-file. But if I don't remember to also remove the data
directory ~/.emacs.d/elpa, then (package-initialize) is *not* a no-op:
it also activates duplicate copies of a bunch of old packages.

> So, it's not that big of a deal, really.

Only if you're OK with leaving a superfluous line in your init-file
for no reason other than that package.el wants it there. I know for a
fact that I'm not the only person who is annoyed by this kind of
behavior: see [1] for example.

Also, if it's not a big deal to have packages automatically insert
code into the user's init-file, then why don't more packages do this?
If every package did this, it would be a disaster. Somehow every
package other than package.el has managed without this mechanism; I
think package.el can do the same.

> We could arrange for "(package-initialize)" to only be added if
> there is at least one package inside ~/.emacs.d/elpa.

That's a good idea but it won't fix the problem, in my opinion. My
expectation of editor plugins is that if I remove the code configuring
them, then they should no longer affect me. This is not the case with
package.el; you have to specifically jump through some extra hoops to
prevent its side-effects from resurrecting themselves in future Emacs
sessions (e.g. deleting ~/.emacs.d/elpa).

> So users of other package managers should simply never bump into
> this text (unless they also user package.el, of course). If they do,
> they should report it as a bug.

Users of other package managers will still encounter this text unless
they delete ~/.emacs.d/elpa. In light of this, I think we have a
documentation bug, since the manual doesn't display a clear notice
that if you want to use an alternative package manager, you !!must!!
delete ~/.emacs.d/elpa first. More to the point, I don't think such a
step should be necessary: what if I wanted to switch between package
managers? That shouldn't be hard; there aren't these kinds of
persistent side effects with any of the other Emacs package managers I
tried, only for package.el.

> Multiple?  Doesn't
>
>     (advice-add 'package--ensure-init-file :override #'ignore)
>
> do the trick?

The second advice I was referring to was preventing
`package--save-selected-packages' from modifying the init-file.
However, the question of `package-selected-packages` is an entirely
separate issue and I shouldn't have snuck it in here. Sorry about
that; pretend I said just one advice.

> I suspect that
>
>     (setq package-enable-at-startup nil)
>
> might also do the trick.

I don't consider `package-enable-at-startup' to be an acceptable
solution, since I might want to use a function from package.el just to
try it out. In that case, my init-file will still get modified without
my permission. The name of the game here is "persistent side effects".
In my opinion, a package manager shouldn't have any. Again, for all
the other Emacs package managers I've seen (including the one I
wrote), you can perform any operations you'd like with them, and after
restarting Emacs, you'll be back where you started provided that you
didn't put anything in your init-file. This also happens to be the
case with every Emacs *package* I've seen. The only exception is
package.el, and I think we should consider why (if?) package.el needs
to be an exception.

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

> Another thing is that rather then look for "(package-initialize)" in
> ~/.emacs we could keep track of whether package-initialize was
> called during initialization. This will avoid the problem when the
> user placed his call in another file.

Actually, Emacs already does this. And it doesn't solve the problem;
quoting from above:

    > Wait, you said that it was a problem if `package-initialize' was
    > put somewhere other than in the init-file. But if it's called
    > during startup, then package.el doesn't run the logic to insert
    > the a call into the init-file. So what's the issue?

    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. This is actually
    terrible, since it immediately makes debugging much more
    complicated: your init-file is being changed without your knowing
    it, while you're trying to debug initialization!

    > OK, but that only happens when there's an error during init. We
    > could make it so that the `package-initialize' happens only
    > after a successful init.

    That doesn't solve the problem, because there are all kinds of
    circumstances where you have a "successful" init even when the
    user's init-file was not loaded. For example, many modular Emacs
    configurations will sustain errors in one or more modules using
    `condition-case', and report the errors as warnings for an
    improved debugging experience. We're back to the beginning.

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

Best,
Radon

[1]: 
https://www.reddit.com/r/emacs/comments/56fvgd/is_there_a_way_to_stop_emacs_from_adding_the/