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: Tue, 22 Aug 2017 22:17:05 -0700 Message-ID: References: <83tw12cocz.fsf@gnu.org> <83wp5xat6i.fsf@gnu.org> <2d035e42-006b-e76e-2b3f-75f2dfd87bb7@taydin.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="f403045ec432055180055764d5ac" X-Trace: blaine.gmane.org 1503465526 31005 195.159.176.226 (23 Aug 2017 05:18:46 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 23 Aug 2017 05:18:46 +0000 (UTC) Cc: angelo.g0@libero.it, Eli Zaretskii , Stefan Monnier , Drew Adams , 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 Wed Aug 23 07:18:41 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 1dkO3o-0007TL-Cj for ged-emacs-devel@m.gmane.org; Wed, 23 Aug 2017 07:18:36 +0200 Original-Received: from localhost ([::1]:38635 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkO3t-0005Cx-D2 for ged-emacs-devel@m.gmane.org; Wed, 23 Aug 2017 01:18:41 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35267) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkO35-0005Bj-8O for emacs-devel@gnu.org; Wed, 23 Aug 2017 01:17:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dkO33-0003DG-He for emacs-devel@gnu.org; Wed, 23 Aug 2017 01:17:51 -0400 Original-Received: from mail-lf0-x233.google.com ([2a00:1450:4010:c07::233]:37731) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dkO33-0003BU-4N; Wed, 23 Aug 2017 01:17:49 -0400 Original-Received: by mail-lf0-x233.google.com with SMTP id f7so2660135lfg.4; Tue, 22 Aug 2017 22:17:46 -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=0oI3JwLJmAIAJtCR0+hWHzByaTmXRxeuskahh0AOYMQ=; b=WXdRfkFfWRlOUU4Fetvj9uqUWAXtxYZnSgHeTdzRCXNi5AASSiDrqxtwJllPRrOv7U tf89TEHPPRKM8gZA/u6Zz3LTmGzkODSJ2c4ioDZEOctcj7Dkc9Bwgi/aJJ8u3RG5aUbr Fq0d6cSPtJ8Q6F8oiVmKSYkpCs/hVIWDr700Jj4rCaGR6+/iY1IQFcJP+QXfVcDh8xXe /X/qjAu2GAJV+lyBtukre1q//gHtcxfkWWlfht0poX1e/qRiEIKTq2vuQdypYd783YXR 6IZBCpHquNqETGRGuazYt4oj1msfCus/++Bj28yj7XwefFSFmH0d97ZJrqviE9Z+k7rE jA7g== 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=0oI3JwLJmAIAJtCR0+hWHzByaTmXRxeuskahh0AOYMQ=; b=MXxCvYvI6GL7Mp7Z+t4ZAXsBXb0695AdNwl9u6FIzN5jYpkngzI2mCarlH5FUZOBM5 0eTr6kljJDf473YpqWG/UJ7tiINfXB8CE8qeq3U1vpr6YSF1qcP7laoUrRbmr5/gB0HK SZVhqQA6qzRv31XcHfYq4Xhou6UMNOSvj94WJ6qtXuUJfIvK9xkP3VHcvVbUIadz3cqD 9O4yvVclYEBzmwkbnFwja4Mz8EdluUQA8U2G10M7+c4HIIbtmZOw+hUNzFpK2epzQlpr xafkG/HLZoKyFggcfkb9SCoggZM7NLRHYixWOos9bn/NWW/Dua1qKsowR8AEIUU7Gimg Vcrw== X-Gm-Message-State: AHYfb5gxzkqhDBo6UyyBfVNzL9zMxvC6TqpuHv/Vnwxsdi4zim+PcCaO 1g/xNwHeYHWidAX0dXkBIotJYQKzzw== X-Received: by 10.46.8.1 with SMTP id 1mr672602lji.67.1503465465792; Tue, 22 Aug 2017 22:17:45 -0700 (PDT) Original-Received: by 10.25.80.3 with HTTP; Tue, 22 Aug 2017 22:17:05 -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::233 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:217714 Archived-At: --f403045ec432055180055764d5ac Content-Type: text/plain; charset="UTF-8" > I think I'm not a big fan of your proposal because the only problem I > see with the status quo is that a call to package-initialize in the > init file is required at all. Thank you for this explanation. It is really helpful, as it helps me see why we have been talking at cross purposes. > I think I don't see package.el as one out of many, but rather as a > core component of Emacs. Given this, I'm inclined to be more > tolerant of exceptions made just for that package. This helps too. It made me realize that package.el really is core to Emacs, which I previously failed to see just because I don't really like package.el as a package manager. > I'd be fine, for example, with saving package.el's configuration in > a separate file that gets loaded early. In light of what I've said above, I would be fine with this too. Specifically, if we: * removed all traces of `package--ensure-init-file' * moved the call to `package-initialize' from after loading the init-file to before loading the init-file * loaded an optional second init-file before `package-initialize' * made absolutely sure that it's trivial to disable package.el permanently and unconditionally by setting `package-enable-at-startup' in this second init-file then I would be perfectly happy and would not bother anyone about this again. I do want to raise two possible points of concern, which I personally am fine with but maybe other people aren't: * doing this would instantly break the configuration of everyone who customizes package.el or uses it in a nonstandard way -- can anyone think of a way to maintain some backward compatibility so Drew can keep his configuration working from Emacs 20 to Emacs 26? ;) * you will get a bunch of bug reports from people trying and failing to customize package.el in their normal init-file, I guarantee it -- but this could at least be minimized by inserting big flashy warnings into the docstrings of all the relevant variables > That file doesn't need to be a full-fledged ELisp file. It could be > an alist of relevant keys and values, like a dir-local file. Bad idea. In particular, this will make it impossible to customize `package-load-list' so that packages are loaded from package.el by default, but can be overridden from a local checkout, which is a pattern I've seen very frequently in the wild. Besides, if we're going to require it to be static, why not just say you can only customize package.el via file-local variables in the primary init-file? (I know, I know, at least you could line-wrap things. But still.) ~~~ Drew, Stefan, Eli -- would you be comfortable with this alternative proposal, to add a second init-file as I've outlined above? It would make package.el "just work" in all cases, without requiring any change to the user's init-file, as long as users read docstrings before customizing `package-load-list' etc., and as long as we're prepared to sacrifice a little backwards compatibility (although maybe we can be smart about it and make the change pretty painless). Angelo -- ... sorry :P I still think that calling package-initialize in the init-file is "the right thing" from an architecture and modularity perspective, but having a second init-file may be a more pragmatic solution. --f403045ec432055180055764d5ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> I think I'm not a big fan of your propo= sal because the only problem I
> see with the status quo is th= at a call to package-initialize in the
> init file is required= at all.

Thank you for this explanation. It is rea= lly helpful, as it helps me
see why we have been talking at cross= purposes.

> I think I don't see package.el= as one out of many, but rather as a
> core component of Emacs= . Given this, I'm inclined to be more
> tolerant of except= ions made just for that package.

This helps too. I= t made me realize that package.el really is core to
Emacs, which = I previously failed to see just because I don't really
like p= ackage.el as a package manager.

> I'd be fi= ne, for example, with saving package.el's configuration in
&g= t; a separate file that gets loaded early.

In ligh= t of what I've said above, I would be fine with this too.
Spe= cifically, if we:

* removed all traces of `package= --ensure-init-file'
* moved the call to `package-initialize&#= 39; from after loading the
=C2=A0 init-file to before loading the= init-file
* loaded an optional second init-file before `package-= initialize'
* made absolutely sure that it's trivial to d= isable package.el
=C2=A0 permanently and unconditionally by setti= ng
=C2=A0 `package-enable-at-startup' in this second init-fil= e

then I would be perfectly happy and would not bo= ther anyone about this
again. I do want to raise two possible poi= nts of concern, which I
personally am fine with but maybe other p= eople aren't:

* doing this would instantly bre= ak the configuration of everyone who
=C2=A0 customizes package.el= or uses it in a nonstandard way -- can anyone
=C2=A0 think of a = way to maintain some backward compatibility so Drew can
=C2=A0 ke= ep his configuration working from Emacs 20 to Emacs 26? ;)
* you = will get a bunch of bug reports from people trying and failing
= =C2=A0 to customize package.el in their normal init-file, I guarantee it --=
=C2=A0 but this could at least be minimized by inserting big fla= shy
=C2=A0 warnings into the docstrings of all the relevant varia= bles

> That file doesn't need to be a full-= fledged ELisp file. It could be
> an alist of relevant keys an= d values, like a dir-local file.

Bad idea. In part= icular, this will make it impossible to customize
`package-load-l= ist' so that packages are loaded from package.el by
default, = but can be overridden from a local checkout, which is a
pattern I= 've seen very frequently in the wild.

Besides,= if we're going to require it to be static, why not just say
= you can only customize package.el via file-local variables in the
primary init-file? (I know, I know, at least you could line-wrap
things. But still.)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 ~~~

Drew, Stefan, Eli -- would you be comforta= ble with this alternative
proposal, to add a second init-file as = I've outlined above? It would
make package.el "just work= " in all cases, without requiring any change
to the user'= ;s init-file, as long as users read docstrings before
customizing= `package-load-list' etc., and as long as we're prepared to
sacrifice a little backwards compatibility (although maybe we can be
smart about it and make the change pretty painless).

<= /div>
Angelo -- ... sorry :P

=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 I still think that calling package-initialize in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 init-file is "the right thing= " from an architecture and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 modularity perspective, but having a second init-file may be
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 a more pragmatic solution.

--f403045ec432055180055764d5ac--