From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Calling (package-initialize) sooner during initialization Date: Sun, 12 Apr 2015 19:22:55 -0400 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1428881004 1094 80.91.229.3 (12 Apr 2015 23:23:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 12 Apr 2015 23:23:24 +0000 (UTC) Cc: Vasilij Schneidermann , emacs-devel To: Jorgen =?windows-1252?Q?Sch=E4fer?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 13 01:23:17 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YhRDg-0000rN-GC for ged-emacs-devel@m.gmane.org; Mon, 13 Apr 2015 01:23:16 +0200 Original-Received: from localhost ([::1]:46503 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YhRDf-0001E0-QS for ged-emacs-devel@m.gmane.org; Sun, 12 Apr 2015 19:23:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53197) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YhRDT-0001Dt-V9 for emacs-devel@gnu.org; Sun, 12 Apr 2015 19:23:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YhRDP-0003Ew-Te for emacs-devel@gnu.org; Sun, 12 Apr 2015 19:23:03 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:45293) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YhRDP-0003Es-Oy for emacs-devel@gnu.org; Sun, 12 Apr 2015 19:22:59 -0400 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id t3CNMuNn021146; Sun, 12 Apr 2015 19:22:56 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 529FF127B; Sun, 12 Apr 2015 19:22:56 -0400 (EDT) In-Reply-To: ("Jorgen =?windows-1252?Q?Sch=E4fer=22's?= message of "Sun, 12 Apr 2015 23:02:58 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV5274=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5274> : inlines <2687> : streams <1421468> : uri <1905141> 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.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:185364 Archived-At: > To make myself a bit more clear, my proposal would mean adding these > lines of code to startup.el just before the user init file is loaded: > (dolist (dir (directory-files "~/.emacs.d/elpa" t "\\`[^.]")) > (when (file-directory-p dir) > (add-to-list 'load-path dir) > (dolist (autoload (directory-files dir t "-autoloads.el\\'")) > (load autoload nil t)))) OK, so it does a minimalist initialization, and the main direct downside is that users can't directly "disable" packages, they have to move them out of ~/.emacs.d/elpa instead. That's not a bad tradeoff, indeed. One more issue is for things like AUCTeX's TeX-modes, which is usually set before auctex-autoloads.el is loaded, but indeed this already needs to handle the case where the var is modified later (which is handled via a :set function), so it's OK. There are a few other issues, tho. For example, the current code first looks at all the installed packages and then only allocates the latest version of each (modulo pinned versions). So you can have several versions of a given package installed (in different directories or not) and package-initialize will know which one to initialize. If we load all of ~/.emacs.d/elpa this won't handle all the corresponding cases anymore. More specifically, we'll end up initializing a package in ~/.emacs.d/elpa even if a more recent version might be installed in some other directory that will be provided later. The main use case would be when the other directory is a system directory, which we could handle by letting sysadmins change the site-start.el file so as to (package-load-descriptors DIR). This way, they're not yet initialized, but package.el knows about it so it could refrain from initializing a less recent package from ~/.emacs.d/elpa. Stefan