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: Wed, 23 Aug 2017 10:31:48 -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="f403045ec432a441d505576f18cf" X-Trace: blaine.gmane.org 1503509575 13622 195.159.176.226 (23 Aug 2017 17:32:55 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 23 Aug 2017 17:32:55 +0000 (UTC) Cc: emacs-devel@gnu.org To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 23 19:32:51 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 1dkZWM-0003Ig-PP for ged-emacs-devel@m.gmane.org; Wed, 23 Aug 2017 19:32:50 +0200 Original-Received: from localhost ([::1]:44978 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkZWT-0000gv-KG for ged-emacs-devel@m.gmane.org; Wed, 23 Aug 2017 13:32:57 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35285) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkZW4-0000YC-Rc for emacs-devel@gnu.org; Wed, 23 Aug 2017 13:32:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dkZW3-0007Nw-RF for emacs-devel@gnu.org; Wed, 23 Aug 2017 13:32:32 -0400 Original-Received: from mail-lf0-x229.google.com ([2a00:1450:4010:c07::229]:34621) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dkZW3-0007Mm-Ee for emacs-devel@gnu.org; Wed, 23 Aug 2017 13:32:31 -0400 Original-Received: by mail-lf0-x229.google.com with SMTP id g77so3589322lfg.1 for ; Wed, 23 Aug 2017 10:32:31 -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=ac57JsbkpQIsDNlFlbqbTp51jcuCVk17DyXFc1r+jaM=; b=XbiuyJAM52elQU99vXOYyViVGJQx1zoTog9Lf7ueeFQMKsdV+ry8t7MeKvbfcMhM/2 Diht4znrG2SO98gcEpz+/PezOeQHOnrk3fWyd7ZRm5/0eHZt8NuyPuG7iU4M2sCTZEJj VM8H5Wld3BSLU0JsM1OjmZJSG+/LcAITZZVtzQoV8RNgyYZhCUVWJNZ5TZyQGoWT1a5z sHFL0CXXhtXCOoPavdIxxVD0jcMDYZGiuChgZV1L2Uu+AWj4lLA0nbZSZAnyoDTo5+Kf 70EvXkWGyD4xK2Sd7ARLtYO0sCwrMbx2Stqutj8G8V+cJOPCCw5ZfuW9QDfiPVxMBuiL 93gg== 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=ac57JsbkpQIsDNlFlbqbTp51jcuCVk17DyXFc1r+jaM=; b=PQYjxMq3d//wL8egEgfGGEks1upURVXv8AFqVRaFhkWm2zJHm8khpoIxHYAH3C1s+M soizg3gjysXnK0gTszYYJRjgnqvos5RGfbutmRvab9FqfEIrnvZaStQ2KcrEH8mYjfGm QHZa15CUMX94QMkBpWN9zMsrgglJc8rDAGHt5Ue0zulUlCSJKPmYLqvctpsDmupJ7k6m ifblB3Pyoc0NMuaeba8WYZZeo/ZE8JemgIouo5cB5ECskOsHLbB+13Lp1I0+bjFZNvLn KB+t2uoyHbDFe4Bepwr5vb8eMKwHqaRJBfr9p7ycIts6NPOMzpazG5aYt677V2TlF4CF 6pEg== X-Gm-Message-State: AHYfb5j1PKdCg//0b8J6NsTHXngDRQyMTBUkyx0s3LQsF2GFtcike7yl ox6OH/HnxlhapMNyLk8BM7VsWDiD6Dldl8M= X-Received: by 10.46.8.1 with SMTP id 1mr1683132lji.67.1503509549955; Wed, 23 Aug 2017 10:32:29 -0700 (PDT) Original-Received: by 10.25.42.215 with HTTP; Wed, 23 Aug 2017 10:31:48 -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::229 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:217727 Archived-At: --f403045ec432a441d505576f18cf Content-Type: text/plain; charset="UTF-8" > To be clear: I do not use the package system Yeah, neither do I. So we're on the same page here. > This is partly because I don't use packages, in general. Remind me to ask why, sometime. > 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 each time I > use Emacs. I know for a fact that there are alternative package managers which are designed for this sort of use case, unlike package.el. > (I would 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.) I doubt this will change soon, as it's a fundamental part of how package.el works. But that's why we have alternative package managers. > But in your proposal the first init file is apparently loaded after > `package-initialize' is done. The order is: 1. Load package.el init-file 2. Run package-initialize, unless package-enable-at-startup was un-set in (1) 3. Load regular init-file 4. Nothing else is done afterwards, unlike currently > So it sounds like users will have `package-initialize' inflicted on > them unconditionally. Wrong. You just (setq package-enable-at-startup nil) in the secondary init-file, and are never bothered by package.el again. This is much better than the current situation, where you still have to (setq package-enable-at-startup nil), but furthermore you have to put an advice on an internal package.el function in order to avoid (package-initialize) from being inserted under some circumstances. --f403045ec432a441d505576f18cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> To be clear: I do not use the package system

Yeah, neither do I. So we're on the same page her= e.

> This is partly because I don't use pac= kages, in general.

Remind me to ask why, sometime.=

> And it is mostly because I use multiple vers= ions 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 each time I
> use Emacs.

I know for a fact that there are alternative package managers which
are designed for this sort of use case, unlike package.el.

> (I would in fact like that to be even easier than no= w. "Installing"
> packages and enabling them seems t= oo monolithic, to me. It seems to
> assume that a given user h= as only one set of preferences, which s?he
> uses all the time= .)

I doubt this will change soon, as it's a fu= ndamental part of how
package.el works. But that's why we hav= e alternative package managers.

> But in your p= roposal the first init file is apparently loaded after
> `pack= age-initialize' is done.

The order is:

1. Load package.el init-file
2. Run package-ini= tialize, unless package-enable-at-startup was un-set
=C2=A0 =C2= =A0in (1)
3. Load regular init-file
4. Nothing else is = done afterwards, unlike currently

> So it sound= s like users will have `package-initialize' inflicted on
>= them unconditionally.

Wrong. You just (setq packa= ge-enable-at-startup nil) in the secondary
init-file, and are nev= er bothered by package.el again. This is much
better than the cur= rent situation, where you still have to (setq
package-enable-at-s= tartup nil), but furthermore you have to put an
advice on an inte= rnal package.el function in order to avoid
(package-initialize) f= rom being inserted under some circumstances.
--f403045ec432a441d505576f18cf--