From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Artur Malabarba Newsgroups: gmane.emacs.devel Subject: Re: Calling (package-initialize) sooner during initialization Date: Mon, 13 Apr 2015 23:52:17 +0100 Message-ID: References: Reply-To: bruce.connor.am@gmail.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113402e03e8be00513a2f771 X-Trace: ger.gmane.org 1428965546 31062 80.91.229.3 (13 Apr 2015 22:52:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 13 Apr 2015 22:52:26 +0000 (UTC) Cc: =?UTF-8?Q?Jorgen_Sch=C3=A4fer?= , Vasilij Schneidermann , emacs-devel To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 14 00:52:25 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 1YhnDM-0002zE-9Q for ged-emacs-devel@m.gmane.org; Tue, 14 Apr 2015 00:52:24 +0200 Original-Received: from localhost ([::1]:53661 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YhnDL-0006xp-Gy for ged-emacs-devel@m.gmane.org; Mon, 13 Apr 2015 18:52:23 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52643) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YhnDH-0006xk-L6 for emacs-devel@gnu.org; Mon, 13 Apr 2015 18:52:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YhnDG-0005no-H8 for emacs-devel@gnu.org; Mon, 13 Apr 2015 18:52:19 -0400 Original-Received: from mail-la0-x22d.google.com ([2a00:1450:4010:c03::22d]:35001) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YhnDG-0005nk-47 for emacs-devel@gnu.org; Mon, 13 Apr 2015 18:52:18 -0400 Original-Received: by labbd9 with SMTP id bd9so69128732lab.2 for ; Mon, 13 Apr 2015 15:52:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=P32og6wXqLMKAeIC1Dm2taMX4F/ZMOjrT/UTgKGM3Ps=; b=JmX6X3Hq9D4AlCQQevpngHo35+8M1REOSgG/8DtQoKq+K1BLXVnlxGMWU3qFu/6IZx zsg6MqEq5q0H72rOrWkZEJkPXknwakqy5xKiNK5SBR4WUj5g4+g5fqzBmXZp5ARSAXM/ wrKG7g6VF2U1l+YE+ByDIRbdz6NyoRe4qwWKMocSW4nFH43rFAWdPmUue5srD8o/wBtN dJzJ0nwp9JFYzQrb3PBLkHTXDQY8OJV9zu2Scg8bVsLjqtE+qHuWsmxDjCEGmvZ8n2Zj eenKHZvbfW6rvBtOBF4FkKDxECvLNsxVcSEOFC7hEVejFWzOfQ6Qa4AWOasuCdumf6/e dQkA== X-Received: by 10.112.29.180 with SMTP id l20mr14731006lbh.95.1428965537252; Mon, 13 Apr 2015 15:52:17 -0700 (PDT) Original-Received: by 10.25.150.131 with HTTP; Mon, 13 Apr 2015 15:52:17 -0700 (PDT) Original-Received: by 10.25.150.131 with HTTP; Mon, 13 Apr 2015 15:52:17 -0700 (PDT) In-Reply-To: X-Google-Sender-Auth: oA_G4BxVCtttNIg0inUmUg5ItGs X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c03::22d 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:185392 Archived-At: --001a113402e03e8be00513a2f771 Content-Type: text/plain; charset=UTF-8 On Apr 13, 2015 12:22 AM, "Stefan Monnier" wrote: > > > 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. I'm fine with this solution too (magnums or rackets), but I wouldn't mind hearing the opinion of people who will be forced to do that. > 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, IIUC, There's another situation where this will come up. If a mass package upgrade fails for some reason, there will be lots of old package directories hanging around in the elpa subdir. So we can't just blindly load all those directories, we'll need to actually parse the packages contained in all of them, version sort them into something like package-alist, and load only the appropriate ones. --001a113402e03e8be00513a2f771 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Apr 13, 2015 12:22 AM, "Stefan Monnier" <monnier@iro.umontreal.ca> w= rote:
>
> > To make myself a bit more clear, my proposal would mean adding th= ese
> > lines of code to startup.el just before the user init file is loa= ded:
>
> > (dolist (dir (directory-files "~/.emacs.d/elpa" t "= ;\\`[^.]"))
> >=C2=A0 =C2=A0(when (file-directory-p dir)
> >=C2=A0 =C2=A0 =C2=A0(add-to-list 'load-path dir)
> >=C2=A0 =C2=A0 =C2=A0(dolist (autoload (directory-files dir t "= ;-autoloads.el\\'"))
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0(load autoload nil t))))
>
> OK, so it does a minimalist initialization, and the main direct downsi= de
> is that users can't directly "disable" packages, they ha= ve to move them
> out of ~/.emacs.d/elpa instead.=C2=A0 That's not a bad tradeoff, i= ndeed.

I'm fine with this solution too (magnums or rackets), bu= t I wouldn't mind hearing the opinion of people who will be forced to d= o that.

> There are a few other issues, tho.=C2=A0 For example, t= he current code first
> looks at all the installed packages and then only allocates the latest=
> version of each (modulo pinned versions).=C2=A0 So you can have severa= l
> 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 corres= ponding
> cases anymore.=C2=A0 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,

IIUC, There's another situation where this will come up.= If a mass package upgrade fails for some reason, there will be lots of old= package directories hanging around in the elpa subdir.

So we can't just blindly load all those directories, we&= #39;ll need to actually parse the packages contained in all of them, versio= n sort them into something like package-alist, and load only the appropriat= e ones.

--001a113402e03e8be00513a2f771--