From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Summary and next steps for (package-initialize) Date: Wed, 23 Aug 2017 06:28:44 -0700 (PDT) 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="__1503494926309152067abhmp0008.oracle.com" X-Trace: blaine.gmane.org 1503494959 1574 195.159.176.226 (23 Aug 2017 13:29:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 23 Aug 2017 13:29:19 +0000 (UTC) Cc: Eli Zaretskii , Stefan Monnier , angelo.g0@libero.it, emacs-devel@gnu.org To: Radon Rosborough , =?utf-8?B?Q2zDqW1lbnQgUGl0LUNsYXVkZWw=?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 23 15:29:11 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 1dkViV-0008KJ-3i for ged-emacs-devel@m.gmane.org; Wed, 23 Aug 2017 15:29:07 +0200 Original-Received: from localhost ([::1]:43739 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkVib-0007J0-KO for ged-emacs-devel@m.gmane.org; Wed, 23 Aug 2017 09:29:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49464) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkViO-0007Ic-GK for emacs-devel@gnu.org; Wed, 23 Aug 2017 09:29:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dkViN-0002pD-3f for emacs-devel@gnu.org; Wed, 23 Aug 2017 09:29:00 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:41114) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dkViI-0002n3-3P; Wed, 23 Aug 2017 09:28:54 -0400 Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v7NDSnBE024839 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 23 Aug 2017 13:28:50 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v7NDSmPP032326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 23 Aug 2017 13:28:49 GMT Original-Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v7NDSkMx019635; Wed, 23 Aug 2017 13:28:46 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 12.0.6774.5000 (x86)] X-Source-IP: userv0022.oracle.com [156.151.31.74] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] [fuzzy] X-Received-From: 141.146.126.69 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:217722 Archived-At: --__1503494926309152067abhmp0008.oracle.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable * doing this would instantly break 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 keep his configuration working from Emacs 20 to Emacs 26? ;) =C2=A0 To be clear: I do not use the package system (except rarely, if I need to c= heck a problem reported by someone). =C2=A0 This is partly because I don't use packages, in general. And it is mostly b= ecause I use multiple versions of Emacs and multiple configurations, for te= sting, and I don't want to be bothered with telling package.el what to do a= nd not do each time I use Emacs. My use case is, I think, different from so= meone who typically wants the same stuff available and turned on in each Em= acs session.=20 =C2=A0 So I don't imagine that what you envision (which I haven't followed in deta= il) should affect me, personally. If I can easily use or not use the packag= e system for any given Emacs session then it will likely be OK by me. (I wo= uld in fact like that to be even easier than now. "Installing" packages and= enabling them seems too monolithic, to me. It seems to assume that a given= user has only one set of preferences, which s?he uses all the time.) =C2=A0 My feedback in this thread is not particularly about how it affects me, per= sonally. It is about how (I think) it affects Emacs users generally (where = by "generally" I mean taking into account their diverse use patterns, not j= ust "mostly" as in a majority of users). =C2=A0 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). =C2=A0 I'm not sure I understand it, i.e., just what changes for users. And just w= hat compatibility loss is there? =C2=A0 For example, you say: =C2=A0 made absolutely sure that it's trivial to disable package.el permanently an= d unconditionally by setting `package-enable-at-startup' in this second ini= t-file =C2=A0 But in your proposal the first init file is apparently loaded after `packag= e-initialize' is done. So it sounds like users will have `package-initializ= e' inflicted on them unconditionally. How does that jibe with choosing not = to use the package system (ever, or for a particular Emacs session)? How is= it trivial to tell package.el "Hands off", if `package-initialize' is alwa= ys done? --__1503494926309152067abhmp0008.oracle.com Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

* doing this would instantly break the c= onfiguration of everyone who

  customizes package.el or uses it in a n= onstandard way -- can anyone

  think of a way to maintain some backwar= d compatibility so Drew can

  keep his configuration working from Emac= s 20 to Emacs 26? ;)

&n= bsp;

To be clear: I do = not use the package system (except rarely, if I need to check a problem= reported by someone).

This is part= ly because I don't use packages, in general. And it is mostly because I use= multiple versions of Emacs and multiple configurations, for testing, and I= don't want to be bothered with telling package.el what to do and not do ea= ch time I use Emacs. My use case is, I think, different from someone who ty= pically wants the same stuff available and turned on in each Emacs session.=

 

So I don't imagine that what you = envision (which I haven't followed in detail) should affect me, personally.= If I can easily use or not use the package system for any given Ema= cs session then it will likely be OK by me. (I would in fact like th= at to be even easier than now. "Installing" packages and enabling= them seems too monolithic, to me. It seems to assume that a given user has= only one set of preferences, which s?he uses all the time.)

 

My feedback in this thread is not particularly ab= out how it affects me, personally. It is about how (I think) it affects Ema= cs users generally (where by "generally" I mean taking into accou= nt their diverse use patterns, not just "mostly" as in a majority= of users).

 = ;

Dre= w, 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 use= r'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 backw= ards compatibility (although maybe we can be

smart about it and make the ch= ange pretty painless).

=  

I'm not sure I unde= rstand it, i.e., just what changes for users. And just what compatibility l= oss is there?

&n= bsp;

For example, you say:=

 

made absolutely s= ure that it's trivial to disable package.el permanently and unconditionally= by setting `package-enable-at-startup' in this second init-file=

 

But in your proposal the first init file is apparently loaded after `pa= ckage-initialize' is done. So it sounds like users will have `package-initi= alize' inflicted on them unconditionally. How does that jibe with choosing = not to use the package system (ever, or for a particular Emacs session)? Ho= w is it trivial to tell package.el "Hands off", if `package-initi= alize' is always done?

<= /body> --__1503494926309152067abhmp0008.oracle.com--