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: Summary and next steps for (package-initialize) Date: Tue, 22 Aug 2017 23:15:28 -0400 Message-ID: References: <83tw12cocz.fsf@gnu.org> <83wp5xat6i.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1503458183 31084 195.159.176.226 (23 Aug 2017 03:16:23 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 23 Aug 2017 03:16:23 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 23 05:16:17 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 1dkM9O-0007db-9g for ged-emacs-devel@m.gmane.org; Wed, 23 Aug 2017 05:16:14 +0200 Original-Received: from localhost ([::1]:57261 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkM9V-0005Y0-1B for ged-emacs-devel@m.gmane.org; Tue, 22 Aug 2017 23:16:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49384) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkM8o-0005XT-9M for emacs-devel@gnu.org; Tue, 22 Aug 2017 23:15:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dkM8k-0006yx-3V for emacs-devel@gnu.org; Tue, 22 Aug 2017 23:15:38 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:57056) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkM8j-0006xL-QC; Tue, 22 Aug 2017 23:15:33 -0400 Original-Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id v7N3FT8q024433; Tue, 22 Aug 2017 23:15:30 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id D1BDA66334; Tue, 22 Aug 2017 23:15:28 -0400 (EDT) In-Reply-To: <83wp5xat6i.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 21 Aug 2017 17:31:33 +0300") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6099=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6099> : inlines <6033> : streams <1759778> : uri <2488201> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 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:217708 Archived-At: >> > I think we should instead explore the possibility that >> > package-initialize will be called only in startup.el. >> I think this is unlikely to work well. 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. > As I said, we should explore this in more detail, and have a detailed > and agreed-upon list of reasons why it's not TRT. 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. 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. > This is hard to interpret without knowing "where you sit". The other alternative will involve comping up with a configuration scheme that is declarative enough to be able to automatically call package-initialize when needed. So it will involve changing the way ~/.emacs is written. This will take many years, and I don't think anyboy has really started this journey, Stefan