From: Radon Rosborough <radon.neon@gmail.com>
To: emacs-devel@gnu.org
Cc: Jonathan H <pythonnut@gmail.com>
Subject: Re: Friendly discussion about (package-initialize)
Date: Sun, 6 Aug 2017 19:16:16 -0700 [thread overview]
Message-ID: <CADB4rJEfxE9_yzFuo2EiyVM9in4iXe24aOVd2eO9sWSOOQbJ4w@mail.gmail.com> (raw)
In-Reply-To: <jwvmv7c6v2o.fsf-monnier+gmane.emacs.devel@gnu.org>
> 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/
next prev parent reply other threads:[~2017-08-07 2:16 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-07 0:37 Friendly discussion about (package-initialize) Radon Rosborough
2017-08-07 1:39 ` Stefan Monnier
2017-08-07 2:16 ` Radon Rosborough [this message]
2017-08-07 2:44 ` Stefan Monnier
2017-08-07 4:12 ` Radon Rosborough
2017-08-09 20:24 ` Stefan Monnier
2017-08-10 3:32 ` Radon Rosborough
2017-08-10 4:25 ` Eli Zaretskii
2017-08-10 4:39 ` Radon Rosborough
2017-08-10 7:24 ` Eli Zaretskii
2017-08-10 17:06 ` Radon Rosborough
2017-08-10 19:08 ` Eli Zaretskii
2017-08-10 19:31 ` Radon Rosborough
2017-08-10 20:00 ` Mark Oteiza
2017-08-11 6:14 ` Eli Zaretskii
2017-08-11 1:25 ` Nick Helm
2017-08-11 21:43 ` Stefan Monnier
2017-08-09 20:35 ` Interoperation between package managers (was: Friendly discussion about (package-initialize)) Stefan Monnier
2017-08-10 3:54 ` Radon Rosborough
2017-08-10 21:34 ` Interoperation between package managers Stefan Monnier
2017-08-11 2:14 ` Radon Rosborough
2017-08-11 22:05 ` Stefan Monnier
2017-08-12 17:54 ` Radon Rosborough
2017-08-12 20:53 ` Jonas Bernoulli
2017-08-13 21:43 ` Stefan Monnier
2017-08-13 21:25 ` Stefan Monnier
2017-08-13 22:42 ` Radon Rosborough
2017-08-13 23:32 ` Stefan Monnier
2017-08-14 0:29 ` Radon Rosborough
2017-08-14 8:02 ` Stefan Monnier
2017-08-23 19:39 ` Nikolay Kudryavtsev
2017-08-23 20:58 ` Radon Rosborough
2017-08-24 12:36 ` Nikolay Kudryavtsev
2017-08-24 20:11 ` Radon Rosborough
2017-08-25 14:31 ` Nikolay Kudryavtsev
2017-08-24 15:04 ` Ted Zlatanov
2017-08-24 15:46 ` Nikolay Kudryavtsev
2017-08-07 3:20 ` Friendly discussion about (package-initialize) Noam Postavsky
2017-08-07 4:14 ` Mark Oteiza
2017-08-08 0:47 ` Stefan Monnier
2017-08-10 20:15 ` Mark Oteiza
2017-08-10 21:29 ` Stefan Monnier
2017-08-11 1:14 ` Mark Oteiza
2017-08-11 8:03 ` Clément Pit-Claudel
2017-08-07 6:52 ` Colin Baxter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CADB4rJEfxE9_yzFuo2EiyVM9in4iXe24aOVd2eO9sWSOOQbJ4w@mail.gmail.com \
--to=radon.neon@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=pythonnut@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.