From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: decision on moving core packages to ELPA; also move to obsolete? Date: Wed, 16 Dec 2020 21:28:35 +0200 Message-ID: <83h7ol8s9o.fsf@gnu.org> References: <86a6ugnopl.fsf@stephe-leake.org> <83im94b17m.fsf@gnu.org> <834kknatxs.fsf@gnu.org> <83sg86apqb.fsf@gnu.org> <865z52oqfp.fsf@stephe-leake.org> <83ft46akpm.fsf@gnu.org> <83o8it8wij.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19901"; mail-complaints-to="usenet@ciao.gmane.io" Cc: daniele@grinta.net, stephen_leake@stephe-leake.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Dec 16 20:34:38 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kpcZJ-00051y-RS for ged-emacs-devel@m.gmane-mx.org; Wed, 16 Dec 2020 20:34:37 +0100 Original-Received: from localhost ([::1]:57866 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kpcZI-0008WO-Tn for ged-emacs-devel@m.gmane-mx.org; Wed, 16 Dec 2020 14:34:36 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49308) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kpcTf-00044T-1d for emacs-devel@gnu.org; Wed, 16 Dec 2020 14:28:48 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:33161) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kpcTe-0001FT-Q7; Wed, 16 Dec 2020 14:28:46 -0500 Original-Received: from [176.228.60.248] (port=1626 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kpcTW-0006x4-W4; Wed, 16 Dec 2020 14:28:44 -0500 In-Reply-To: (message from Stefan Monnier on Wed, 16 Dec 2020 13:46:37 -0500) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:261037 Archived-At: > From: Stefan Monnier > Cc: stephen_leake@stephe-leake.org, daniele@grinta.net, emacs-devel@gnu.org > Date: Wed, 16 Dec 2020 13:46:37 -0500 > > >> What I'm suggesting is the following: > >> - the tarball we build will include the same file as before in > >> `emacs/lisp`. > >> - it will additionally contain a new directory `emacs/elpa` in which > >> each bundled package has its own directory (all in the normal format > >> of installed packages in ~/.emacs.d/elpa). > > So we will have 2 copies of each package's Lisp files in the tarball? > > No, just one, the one in the `emacs/elpa` directory. So what did you mean by "the tarball will include the same file as before in emacs/lisp"? which file will that be, and how is it different from what will be in emacs/elpa? > >> We could also place some or all of the bundled packages directly inside > >> `lisp` > > Now I'm confused: how 'lisp/' is different from 'emacs/lisp' you > > mentioned above? > > It's the same thing. I just omitted to write the "emacs/" prefix that time. Still confused: how is that different from the first alternative, where you said the file will be in emacs/lisp? > > What are the pros and cons of each of these 2 alternatives? I think > > we should carefully consider them before deciding which one we prefer. > > Basically, the question is whether the autoloads of those ELPA packages > are processed once and for all when we dump Emacs (like we do for all > the packages that come with Emacs), or whether that's done during > `package-activate-all` (i.e. between `early-init.el` and `init.el`). > > Doing it at dump time gives better startup times, at the cost of making > it impossible for the end-user to prevent activation of a package (they > can still undo the activation after the fact, of course, but that needs > to be done in ad-hoc ways). > > I think as a first step we should keep those bundled ELPA packages more > like normal ELPA packages (i.e. activate them from > `package-activate-all` rather than when dumping Emacs). We can later > revise this (even on a per-package basis) once we have more experience. I actually like the other alternative, because people will want faster startup, and because it makes no sense to let users disable bundled packages. If we think people will want to disable a package, we shouldn't bundle it.