From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Friendly discussion about (package-initialize) Date: Sun, 06 Aug 2017 22:44:53 -0400 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1502073912 20199 195.159.176.226 (7 Aug 2017 02:45:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 7 Aug 2017 02:45:12 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 07 04:45:08 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 1deY2V-00053T-Pk for ged-emacs-devel@m.gmane.org; Mon, 07 Aug 2017 04:45:07 +0200 Original-Received: from localhost ([::1]:35098 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1deY2b-0008Os-Ne for ged-emacs-devel@m.gmane.org; Sun, 06 Aug 2017 22:45:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55785) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1deY2V-0008MU-Gc for emacs-devel@gnu.org; Sun, 06 Aug 2017 22:45:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1deY2S-0003u0-6O for emacs-devel@gnu.org; Sun, 06 Aug 2017 22:45:07 -0400 Original-Received: from [195.159.176.226] (port=37087 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1deY2R-0003sh-VN for emacs-devel@gnu.org; Sun, 06 Aug 2017 22:45:04 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1deY2H-0004J2-N1 for emacs-devel@gnu.org; Mon, 07 Aug 2017 04:44:53 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 82 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:Izbg09t5Fz1UZBf81zhIKwu8+Lc= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 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:217351 Archived-At: > 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/ 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