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 11:32:55 -0700 Message-ID: References: <83tw12cocz.fsf@gnu.org> <83wp5xat6i.fsf@gnu.org> <2d035e42-006b-e76e-2b3f-75f2dfd87bb7@taydin.org> <58ac4c14-3f26-4b21-806a-aa2326ce3d2b@default> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="f403045ea3ca29e6e405576ff318" X-Trace: blaine.gmane.org 1503513234 23025 195.159.176.226 (23 Aug 2017 18:33:54 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 23 Aug 2017 18:33:54 +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 20:33:50 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 1dkaTH-0005RN-R7 for ged-emacs-devel@m.gmane.org; Wed, 23 Aug 2017 20:33:44 +0200 Original-Received: from localhost ([::1]:45201 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkaTO-0003Rt-F6 for ged-emacs-devel@m.gmane.org; Wed, 23 Aug 2017 14:33:50 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49176) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkaTD-0003Rm-KB for emacs-devel@gnu.org; Wed, 23 Aug 2017 14:33:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dkaTC-0001VN-51 for emacs-devel@gnu.org; Wed, 23 Aug 2017 14:33:39 -0400 Original-Received: from mail-lf0-x22b.google.com ([2a00:1450:4010:c07::22b]:36920) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dkaTB-0001Uv-Q0 for emacs-devel@gnu.org; Wed, 23 Aug 2017 14:33:38 -0400 Original-Received: by mail-lf0-x22b.google.com with SMTP id f7so4103386lfg.4 for ; Wed, 23 Aug 2017 11:33:37 -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=Jtn4+hUna82FAmQanD8fta4jY4fDPGqvamchi9YkL3U=; b=D+AuQVH9sFur8bOgBP//TJ4uD8//nfWKrqhvL1IaLMSQbrzEt3fMVJTTQN8XYgOOch sTf2vT6wilAPDnr1GXAQfjW8OFfXY6WVpvHVcUkB37DlMAKy5lDfvC+VabeaoDGESGS3 Dd9EuqVj7OLz0bK1AimQv6/+ycim/BhoDhCdclIKjvYT+Z4zhaBVygI2xJ9vU3EVewjr MCa75D8bFfs8Jpb79TBjxIZJvxpAdfkQhX+iLJ1F8BY9SviJ2pkQhoBItkG+fb+xpCDV NVX5R9ORBZ97jfDqXrbpqsbFzycqqi8xLFAoF+PMVFLpHUqxb9XYRRE7joMDgQCPvmxI hhIg== 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=Jtn4+hUna82FAmQanD8fta4jY4fDPGqvamchi9YkL3U=; b=s5MV7VeW9B8cgVYdECoJIHDtr3eQHZwlWfmLapvHjNRrVqmhHNhJuBVQiiZnQwWV0U nSG/+PGncLUhM5sR3jhTOST/Ykq4zRv/OV9gij+dUqbLcB81/9WCUZ8pjOjM2t9rUhkx tqxIdeL29iYbttokbnRwSdUDo7pAvKf9J7H0xG3sejtRGBpVQqlUg/pfTn6IjMwVnljR JPKGbQBWUa461US4zeQ/HuW13FzrtLiCM2/3pRiMVbhZCUDt+1pcYe8tBuqgDNE5jdhs jDZ/LKQYyPB02WYLjuojIhRRPMw73aiL02DDYoqn4KCN55AjbF1RHLH32lm2I+EQi5om ef3w== X-Gm-Message-State: AHYfb5hPx8AywuQ88NzbvVLm/P2EtHKyCZzEAVB6G/79WgBteyKXU1td mML+KcNQoL2cgJgGdcUf73o/QJi1r3ZOf0y56Q== X-Received: by 10.25.100.81 with SMTP id b17mr1353575lfj.237.1503513216147; Wed, 23 Aug 2017 11:33:36 -0700 (PDT) Original-Received: by 10.25.42.215 with HTTP; Wed, 23 Aug 2017 11:32:55 -0700 (PDT) In-Reply-To: <58ac4c14-3f26-4b21-806a-aa2326ce3d2b@default> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4010:c07::22b 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:217731 Archived-At: --f403045ea3ca29e6e405576ff318 Content-Type: text/plain; charset="UTF-8" > Again? How about not being bothered the first time? It sounds like > `package-initialize' is evaluated the first time, unconditionally. This is wrong. `package-initialize' is called only once, in step (2). This step happens before loading the primary init-file, but after loading the secondary init-file. If you set `package-enable-at-startup' to nil in the secondary init-file, then `package-initialize' will never be evaluated under any circumstances. > And it sounds like, even if I don't use the package system, I will > have to edit a secondary init file (the first one read), just to > tell package.el "Hands off!" You will have to do that only once in the entire history of your dotfiles. No longer is `package-initialize' called after loading the primary init-file, so a single `setq' is all that is needed to permanently disable package.el. > And if I want to try a package in a particular Emacs session then I > need to once again edit that first ("secondary") init file, to > enable the package system. Is that right? No, it's wrong. To try a package, all you have to do is run M-x package-initialize. In fact, if it's a new package you are installing, M-x package-install will suffice, as package.el is initialized automatically when you try to use it. > It's hard to believe this has to be so convoluted. It seems very simple to me. The package manager is initialized before reading the init-file, unless you tell it not to do that. And in any case, you can initialize it later. The only nonstandard part of this is that the code to disable automatic initialization goes in a separate file. > (But I understand that you are saying that what you propose is less > convoluted than what we have now.) Oh heck yes. Even I don't really understand the full ramifications of the current system. > It seems to me that use of package.el should be just like use of any > other library. Users should explicitly opt in. But I understand that > you've said that it has been decided to enable the package system by > default for everyone, at the outset. The rationale for this decision was that we want to treat package.el as a core part of Emacs rather than as an extension. If you want to debate that, then fine (I might join you), but let's take it as granted for a moment. If package.el is a core part of Emacs, then we expect all of its features to work by default. And we also expect libraries installed using package.el to work similarly to libraries that are shipped with Emacs. That's why it's enabled by default. Note that I'm not really complaining about this decision, even though I don't like package.el and never use it. It seems reasonable to me for the built-in package manager to act like this, even if I don't use said package manager. > It doesn't matter, IMO, if 99% of the users want to opt in; it > should still be opt-in. It really depends on whether you view package.el as a core part of Emacs or not. After all, the menu and tool bars are turned on by default; VC is turned on by default (even though lots of people turn it off and use Magit); why shouldn't the package manager be turned on by default? I think it's fine for stuff to be turned on by default as long as it's easy to turn it off again and swap in something else: (menu-bar-mode -1) (tool-bar-mode -1) (setq vc-handled-backends nil) (setq package-enable-at-startup nil) --f403045ea3ca29e6e405576ff318 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Again? How about not being bothered the first ti= me? It sounds like
> `package-initialize' is evaluated the= first time, unconditionally.

This is wrong. `pack= age-initialize' is called only once, in step (2).
This step h= appens before loading the primary init-file, but after
loading th= e secondary init-file. If you set
`package-enable-at-startup'= to nil in the secondary init-file, then
`package-initialize'= will never be evaluated under any circumstances.

= > And it sounds like, even if I don't use the package system, I will=
> have to edit a secondary init file (the first one read), ju= st to
> tell package.el "Hands off!"

<= /div>
You will have to do that only once in the entire history of your<= /div>
dotfiles. No longer is `package-initialize' called after load= ing the
primary init-file, so a single `setq' is all that is = needed to
permanently disable package.el.

> And if I want to try a package in a particular Emacs session then I<= /div>
> need to once again edit that first ("secondary") i= nit file, to
> enable the package system. Is that right?
=

No, it's wrong. To try a package, all you have= to do is run M-x
package-initialize. In fact, if it's a new = package you are installing,
M-x package-install will suffice, as = package.el is initialized
automatically when you try to use it.

> It's hard to believe this has to be = so convoluted.

It seems very simple to me. The pac= kage manager is initialized before
reading the init-file, unless = you tell it not to do that. And in any
case, you can initialize i= t later. The only nonstandard part of this
is that the code to di= sable automatic initialization goes in a
separate file.

> (But I understand that you are saying that what you pr= opose is less
> convoluted than what we have now.)
<= br>
Oh heck yes. Even I don't really understand the full rami= fications of
the current system.

> It= seems to me that use of package.el should be just like use of any
> other library. Users should explicitly opt in. But I understand that=
> you've said that it has been decided to enable the pack= age system by
> default for everyone, at the outset.

The rationale for this decision was that we want to treat p= ackage.el
as a core part of Emacs rather than as an extension. If= you want to
debate that, then fine (I might join you), but let&#= 39;s take it as
granted for a moment. If package.el is a core par= t of Emacs, then we
expect all of its features to work by default= . And we also expect
libraries installed using package.el to work= similarly to libraries
that are shipped with Emacs. That's w= hy it's enabled by default.

Note that I'm = not really complaining about this decision, even though
I don'= ;t like package.el and never use it. It seems reasonable to me
fo= r the built-in package manager to act like this, even if I don't use
said package manager.

> It doesn't = matter, IMO, if 99% of the users want to opt in; it
> should s= till be opt-in.

It really depends on whether you v= iew package.el as a core part of
Emacs or not. After all, the men= u and tool bars are turned on by
default; VC is turned on by defa= ult (even though lots of people turn
it off and use Magit); why s= houldn't the package manager be turned on
by default?

I think it's fine for stuff to be turned on by defaul= t as long as it's
easy to turn it off again and swap in somet= hing else:

=C2=A0 =C2=A0 =C2=A0(menu-bar-mode -1)<= /div>
=C2=A0 =C2=A0 =C2=A0(tool-bar-mode -1)
=C2=A0 =C2=A0 = =C2=A0(setq vc-handled-backends nil)
=C2=A0 =C2=A0 =C2=A0(setq pa= ckage-enable-at-startup nil)

--f403045ea3ca29e6e405576ff318--