From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Radon Rosborough Newsgroups: gmane.emacs.devel Subject: Re: Friendly discussion about (package-initialize) Date: Sun, 6 Aug 2017 19:16:16 -0700 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1502072263 25722 195.159.176.226 (7 Aug 2017 02:17:43 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 7 Aug 2017 02:17:43 +0000 (UTC) Cc: Jonathan H To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 07 04:17:36 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1deXbp-000686-UM for ged-emacs-devel@m.gmane.org; Mon, 07 Aug 2017 04:17:34 +0200 Original-Received: from localhost ([::1]:35018 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1deXbw-0002W6-9r for ged-emacs-devel@m.gmane.org; Sun, 06 Aug 2017 22:17:40 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47033) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1deXbI-0002VF-Lq for emacs-devel@gnu.org; Sun, 06 Aug 2017 22:17:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1deXbG-0006oZ-JO for emacs-devel@gnu.org; Sun, 06 Aug 2017 22:17:00 -0400 Original-Received: from mail-lf0-x235.google.com ([2a00:1450:4010:c07::235]:35455) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1deXbG-0006oD-7U for emacs-devel@gnu.org; Sun, 06 Aug 2017 22:16:58 -0400 Original-Received: by mail-lf0-x235.google.com with SMTP id t128so24615028lff.2 for ; Sun, 06 Aug 2017 19:16:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GKvffHsXG2iZAyS/R+NKgkVZ1fjwi3yXbGVisrn+byQ=; b=VYLBF0le70a+w2ISO0JPhYfsnwQNBph690ABAXgJ5qOoOQqxGBHS36MW6LgBmH22Oi HpYzkTfaJOY/JTETI9a+qyPdt6pvbLRDODN/qkLJGA6Wl7l0Wn7TehhXOTtMG6bike9d QHTLdlxEK39cXD8CnRelwgSl1N6IZXDnCcIslUGKIDJtCOgJrvwCA8dbwzqyK5VExEwo 9/zYQQG529uLtrYKtAgyUPSnw6XIcpqpci+FUGjQ0snEoMYCFa467Dk5iPzpJcb9pm5i vWRr8rMr0TTTX8a8ZZxbU7kIiH6ANW0SGLh5L7iGoN0spb5CaCdnAAuVo8ntNmjUaoQb j/vA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GKvffHsXG2iZAyS/R+NKgkVZ1fjwi3yXbGVisrn+byQ=; b=AHb6HPeE3x7qhjum96tPGE9jccKuCX7rw7BnJznMLeG99yJ2HDlbYo4xsI+hsLKZco dsGUXksjpMhdF+LrPnHNgyAdPJeTO+yGBgurLU7kHRW9vpCGDOXFNWKBocfJuaiMFa/6 1hqf/JHFYLPkwEg9vfCK7k5ODie+7+PVDlZto2Ijse65laq1xilsfv17eEM/slEUoq3e uZ23UuVWjfTx0JxcaPNcpd34IngUlrpeogoNQpNw0caFmqyJzHi7uTofMVwmZNgu1V6n WdQbiP8FLBMvErUFvDJqMR4X8/OZ9NQtGl+Gsr/FzoEC10L81CSTdKvvLQl8ooVGpmGW SG6g== X-Gm-Message-State: AHYfb5iOfMK0nLIkVvRNzpTuLiYH83yTZIozBKNg5iShFW72wPnZnzku 8ikyBiUg1YiqQTF9MtYFPT9niwRfdiHXW9Y= X-Received: by 10.46.74.10 with SMTP id x10mr3010475lja.154.1502072216607; Sun, 06 Aug 2017 19:16:56 -0700 (PDT) Original-Received: by 10.46.64.86 with HTTP; Sun, 6 Aug 2017 19:16:16 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4010:c07::235 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:217350 Archived-At: > 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/