From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Radon Rosborough Newsgroups: gmane.emacs.devel Subject: Re: Summary and next steps for (package-initialize) Date: Sun, 20 Aug 2017 10:21:40 -0700 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1503249829 5743 195.159.176.226 (20 Aug 2017 17:23:49 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 20 Aug 2017 17:23:49 +0000 (UTC) Cc: emacs-devel@gnu.org To: =?UTF-8?Q?Cl=C3=A9ment_Pit=2DClaudel?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 20 19:23:45 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 1djTwr-00012D-E6 for ged-emacs-devel@m.gmane.org; Sun, 20 Aug 2017 19:23:41 +0200 Original-Received: from localhost ([::1]:40749 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1djTwy-0001rB-4q for ged-emacs-devel@m.gmane.org; Sun, 20 Aug 2017 13:23:48 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36270) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1djTvb-0000vV-JD for emacs-devel@gnu.org; Sun, 20 Aug 2017 13:22:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1djTva-0000To-Iv for emacs-devel@gnu.org; Sun, 20 Aug 2017 13:22:23 -0400 Original-Received: from mail-lf0-x235.google.com ([2a00:1450:4010:c07::235]:34990) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1djTva-0000T4-BK for emacs-devel@gnu.org; Sun, 20 Aug 2017 13:22:22 -0400 Original-Received: by mail-lf0-x235.google.com with SMTP id k186so2987164lfe.2 for ; Sun, 20 Aug 2017 10:22:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4Vv9Ere+NdShQCPHbpnwIo+6BFvHtxqFiGpLZErIZ4w=; b=GgHw+PdyB8p0WY9O5PvRSaqKMjoGG14MdRmuTm9jziQMCytP8zmyyuGoa9NaLyq24m Fi9g1CHYwvbhe0HWq2QiCUsyZD9ZEv2FLCAstAY5A8y9TLeWdUlCSEtYJyF8fLoaJBma ZNdKQt+c5YMd2EDpi/f1yMZAZ6MSHZcmTI/1auUI9aYuBFZRpk9Ywx7ADE/0Igohk6A0 z5VZTHIpJ8V+lX0FYO/x3I9AIJTgA91dmfx4zOILFx3jXIeDTRgTX67GVZ0Bt2Ed6xwn mjNuCTcvldWN20f8zjnrm+vHbGSC3hlL/4ba79MexDyUmktUJN4XjbALsHS7SYZtPZXc cpNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4Vv9Ere+NdShQCPHbpnwIo+6BFvHtxqFiGpLZErIZ4w=; b=k5YTSFH6O75uLaiQRTtCRlcDMcOGYQg2dVVfSKKmZwh97S2U7WbF7dsX1l4u5vTxUT WsaH6t3c+ViBj2ylSP377h/DqrMqFNFCoEsS0I5It1Kf6O4/07oFkNBVRPNHbCvEFZ/e s1VORpPexRWuS1lu2ZGswvlFZ47WpjT1DkytZxxjoLyspkYF34N0QNHTOZxE0jxkeYe3 +ZUI/XBoReFaTo2pbzQz/MdXh9MzF662HiN8jyaEbv5yrenDeK0UVwuIzup+irZlh4QN Mc7qH31FEORo+x0RrBVWm+GW9dY121iehDdQx3uTuFtTKeuSheBCpnn6xaWS7Oks+aFo 7v8Q== X-Gm-Message-State: AHYfb5j946K3irJX7s1Sng4VnZ9mhhiY7WenyUaUt6QWgm1vmOpxruyJ xYtVLU8bNMQoqJR242LJqCqDBGuxdA== X-Received: by 10.25.59.213 with SMTP id d82mr4484380lfl.37.1503249741119; Sun, 20 Aug 2017 10:22:21 -0700 (PDT) Original-Received: by 10.25.80.3 with HTTP; Sun, 20 Aug 2017 10:21:40 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4010:c07::235 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:217639 Archived-At: > Thanks for putting this proposal together. Can you explain what > advantages it holds over my previous proposal, which didn't require > creating an init file if there was none, nor having an explicit > package-initialize form? Sure. I think your proposal would work in principle, but it seems like an unnecessarily complicated way to solve a simple problem. No other package in Emacs requires this level of infrastructure just to customize and use it: why does package.el need it? (I've asked this question before, comparing package.el to other packages and package managers, and have not yet received an answer as to why package.el has to be so special.) That said, here are the concrete disadvantages I see with your proposal: * It is impossible to customize `package-load-list'. If `package-initialize' is called before loading the init-file, and then I call `package-set-load-list' in order to load only a subset of packages, it won't have any effect since all the packages were already loaded the first time `package-initialize' was called. Since `package-initialize' is called once, explicitly, in my proposal, there is no such problem. * More generally, `package-initialize' will be called before my customizations of package.el. If I customize `package-user-dir', then I think I can reasonably expect that only packages in the new location, and not ones in ~/.emacs.d/elpa, will be activated. Not so with your proposal; packages in both locations will be activated. Again, this problem does not exist in my proposal since users simply do the obvious thing: put package.el customizations before calling (package-initialize). * Every other variable in Emacs is customized by setting it to a value. It is confusing for package.el to be customized by adding a special dotfile to ~/.emacs.d. My proposal requires no such inconsistency and therefore does not violate the Principle of Least Surprise. * I find it hard to believe that we won't see significant performance regressions with the current implementation of package.el. Thus your proposal can't be adopted until the implementation is fixed so that calling `package-initialize' multiple times takes negligible extra time. OTOH, my proposal can be adopted right now. The first two points are the real problems here: fundamentally I think it's a non-starter to call `package-initialize' before loading the init-file. Unless, of course, you introduce a new init-file that's called before `package-initialize', and that's a whole new can of worms.