From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Summary and next steps for (package-initialize) Date: Thu, 24 Aug 2017 19:47:05 +0300 Message-ID: <83pobk9aly.fsf@gnu.org> References: <83tw12cocz.fsf@gnu.org> <83wp5xat6i.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1503593937 10203 195.159.176.226 (24 Aug 2017 16:58:57 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 24 Aug 2017 16:58:57 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 24 18:58:52 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 1dkvSy-0002CE-4I for ged-emacs-devel@m.gmane.org; Thu, 24 Aug 2017 18:58:48 +0200 Original-Received: from localhost ([::1]:49545 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkvT4-0007Wp-Un for ged-emacs-devel@m.gmane.org; Thu, 24 Aug 2017 12:58:54 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36408) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkvHw-0007QU-Oc for emacs-devel@gnu.org; Thu, 24 Aug 2017 12:47:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dkvHs-0002qg-AI for emacs-devel@gnu.org; Thu, 24 Aug 2017 12:47:24 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:42221) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkvHs-0002qF-4E; Thu, 24 Aug 2017 12:47:20 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4386 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dkvHr-0006oq-9K; Thu, 24 Aug 2017 12:47:19 -0400 In-reply-to: (message from Stefan Monnier on Tue, 22 Aug 2017 23:15:28 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:217771 Archived-At: > From: Stefan Monnier > Cc: emacs-devel@gnu.org > Date: Tue, 22 Aug 2017 23:15:28 -0400 > > Re-reading what you wrote, I realize that I wrongly interpreted "only in > startup.el" to mean "after loading the .emacs", whereas My suggestion to > "call package-initialize before reading ~/.emacs" would actually also > imply that package-initialize is only called in startup.el. > > So we're probably in agreement. Yes, I think so. > Calling it in startup.el means either calling it before or after loading > ~/.emacs, AFAICT. > > Calling it after ~/.emacs (like we currently do) is too late since it > means that ~/.emacs can't use installed packages, and that several > configurations can't be done in the usual way. > > Calling it before ~/.emacs means that package-initialize is done before > the user got a chance to configure package.el. So we need'd to provide > some way to reproduce the behavior you can currently get by setting > various package.el vars before calling package-initialize. E.g. we > could let a second call to package-initialize de-activate previously > activated packages and activate previously not activated packages. Would a ~/.emacs.d/.package-initialize.el file, to be read by package-initialize before it does anything else, be a better alternative for configurations that must be done before package-initialize is called? Or maybe you have some other alternative ideas for how to make this happen? > Packages bundled with Emacs are activated (long) before loading > ~/.emacs, so calling package-initialize before ~/.emacs seems like the > most natural behavior in that it makes ELPA packages behave similarly to > bundled packages. > > But then we need some way to deal with users setting > package-directory-list or package-pinned-packages or package-user-dir > after package-initialize was called. Right, which is why I suggested to have a separate file for that. Thanks.