GNU bug report logs - #21423
24.5; (package-initialize) added to init.el without (setq package-enable-at-startup nil)

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 21423 in the body.
You can then email your comments to 21423 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Phil Sainty <psainty <at> orcon.net.nz>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.5; (package-initialize) added to init.el without (setq
 package-enable-at-startup nil)
Date: Sun, 06 Sep 2015 23:01:08 +1200

[Message part 1 (text/plain, inline)]

package--ensure-init-file inserts (package-initialize) into the user's
init file, but it does not also insert (setq package-enable-at-startup nil),
which means that (according to (emacs) Package Installation) Emacs will
re-initialize the packages post-init:

> In some circumstances, you may want to load packages explicitly in
> your init file (usually because some other code in your init file
> depends on a package).  In that case, your init file should call the
> function ‘package-initialize’.  It is up to you to ensure that
> relevant user options, such as ‘package-load-list’ (see below), are
> set up prior to the ‘package-initialize’ call.  You should also set
> ‘package-enable-at-startup’ to ‘nil’, to avoid loading the packages
> again after processing the init file.

[0001-Disable-package-enable-at-startup-when-forcing-packa.patch (text/x-patch, attachment)]

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Phil Sainty <psainty <at> orcon.net.nz>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: 24.5; (package-initialize) added to init.el without (setq
 package-enable-at-startup nil)
Date: Sun, 06 Sep 2015 23:10:25 +1200

[Message part 1 (text/plain, inline)]

I managed to configure an incorrect email address for myself.

I've attached the corrected patch to this reply.

[0001-Disable-package-enable-at-startup-when-forcing-packa.patch (text/x-patch, attachment)]

Message #11 received at 21423 <at> debbugs.gnu.org (full text, mbox):

From: Artur Malabarba <bruce.connor.am <at> gmail.com>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: 21423 <at> debbugs.gnu.org
Subject: Re: bug#21423: 24.5; (package-initialize) added to init.el without
 (setq package-enable-at-startup nil)
Date: Sun, 6 Sep 2015 13:59:22 +0100

I think I'd rather do the patch below.
This will not only help the situation where we automatically add
`(package-initialize)' to the init file, but it will also help those
users who have manually added it without knowing about this caveat.

Does anyone foresee problems with this?


From 94dafb46f7f258cb19929efc8bb9c123f428bcc5 Mon Sep 17 00:00:00 2001
From: Artur Malabarba <bruce.connor.am <at> gmail.com>
Date: Sun, 6 Sep 2015 13:52:54 +0100
Subject: [PATCH] * lisp/emacs-lisp/package.el (package-initialize): Set
 enable-at-startup

When `package-initialize' is called as part of loading the init file,
the user probably doesn't want it to be called again afterwards. In this
situation, `package-initialize' now sets `package-enable-at-startup' to
nil to prevent that. The user can have the old behaviour by setting this
variable to t after the call to `package-initialize'.  (Bug#21423)
---
 lisp/emacs-lisp/package.el | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el
index 7c4f21f..57b35ca 100644
--- a/lisp/emacs-lisp/package.el
+++ b/lisp/emacs-lisp/package.el
@@ -1378,7 +1378,9 @@ it to the file."
   (if (equal user-init-file load-file-name)
       ;; If `package-initialize' is being called as part of loading
       ;; the init file, it's obvious we don't need to ensure-init.
-      (setq package--init-file-ensured t)
+      (setq package--init-file-ensured t
+            ;; And likely we don't need to run it again after init.
+            package-enable-at-startup nil)
     (package--ensure-init-file))
   (package-load-all-descriptors)
   (package-read-all-archive-contents)
-- 
2.5.1

Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Phil Sainty <psainty <at> orcon.net.nz>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: 24.5; (package-initialize) added to init.el without (setq
 package-enable-at-startup nil)
Date: Mon, 07 Sep 2015 01:18:46 +1200

[Message part 1 (text/plain, inline)]

...and I'd copied and pasted an unwanted paren from the original line,
so that patch was broken anyway. Now fixed and tested.

In addition I realised the comments needed tweaking to match the change;
and I spotted another (related) bug whereby the code which looks for
calls to (package-initialize) doesn't take its optional argument into
account, so I've modified those searches too.

[0001-Disable-package-enable-at-startup-when-forcing-packa.patch (text/x-patch, attachment)]

Message #17 received at 21423 <at> debbugs.gnu.org (full text, mbox):

From: Phil Sainty <psainty <at> orcon.net.nz>
To: bruce.connor.am <at> gmail.com
Cc: 21423 <at> debbugs.gnu.org
Subject: Re: bug#21423: 24.5; (package-initialize) added to init.el without
 (setq package-enable-at-startup nil)
Date: Mon, 07 Sep 2015 01:29:01 +1200

On 07/09/15 00:59, Artur Malabarba wrote:
> I think I'd rather do the patch below.
> This will not only help the situation where we automatically add
> `(package-initialize)' to the init file, but it will also help those
> users who have manually added it without knowing about this caveat.
>
> Does anyone foresee problems with this?

I did always think it odd that your proposed change wasn't how it
worked to begin with.

That said, this change would seem to be an issue for anyone who is
performing a partial initialisation in their init file (for specific
packages), and then depending on the default initialisation to deal
with the remainder, post-init.

I can only imagine that's a very small proportion of users indeed,
but I presume the scenario ought to be considered (even if only for
the purposes of documenting it in NEWS).

Message #20 received at 21423 <at> debbugs.gnu.org (full text, mbox):

From: Artur Malabarba <bruce.connor.am <at> gmail.com>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: 21423 <at> debbugs.gnu.org
Subject: Re: bug#21423: 24.5; (package-initialize) added to init.el without
 (setq package-enable-at-startup nil)
Date: Sun, 6 Sep 2015 16:21:32 +0100

2015-09-06 14:29 GMT+01:00 Phil Sainty <psainty <at> orcon.net.nz>:
> On 07/09/15 00:59, Artur Malabarba wrote:
>> I think I'd rather do the patch below.
>> This will not only help the situation where we automatically add
>> `(package-initialize)' to the init file, but it will also help those
>> users who have manually added it without knowing about this caveat.
>>
>> Does anyone foresee problems with this?
>
> I did always think it odd that your proposed change wasn't how it
> worked to begin with.
>
> That said, this change would seem to be an issue for anyone who is
> performing a partial initialisation in their init file (for specific
> packages), and then depending on the default initialisation to deal
> with the remainder, post-init.
>
> I can only imagine that's a very small proportion of users indeed,
> but I presume the scenario ought to be considered (even if only for
> the purposes of documenting it in NEWS).

Yes, they'll have to add (setq package-enable-at-startup t) after
calling initialize. That should definitely go in the NEWS.

Message #23 received at 21423 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Artur Malabarba <bruce.connor.am <at> gmail.com>
Cc: Phil Sainty <psainty <at> orcon.net.nz>, 21423 <at> debbugs.gnu.org
Subject: Re: bug#21423: 24.5;
 (package-initialize) added to init.el without (setq
 package-enable-at-startup nil)
Date: Sun, 06 Sep 2015 18:33:46 -0400

>> That said, this change would seem to be an issue for anyone who is
>> performing a partial initialisation in their init file (for specific
>> packages), and then depending on the default initialisation to deal
>> with the remainder, post-init.
>> 
>> I can only imagine that's a very small proportion of users indeed,
>> but I presume the scenario ought to be considered (even if only for
>> the purposes of documenting it in NEWS).

> Yes, they'll have to add (setq package-enable-at-startup t) after
> calling initialize. That should definitely go in the NEWS.

I have a hard time imagining many users doing that.  As a user, if I'm
picky enough to try and do a partial initialization in my init file,
I'll probably also want to do the final full initialization explicitly
in my init file.


        Stefan

Message #28 received at 21423-done <at> debbugs.gnu.org (full text, mbox):

From: Artur Malabarba <bruce.connor.am <at> gmail.com>
To: 21423-done <at> debbugs.gnu.org
Subject: Re: bug#21423: 24.5; (package-initialize) added to init.el without
 (setq package-enable-at-startup nil)
Date: Mon, 7 Sep 2015 11:26:38 +0100

Pushed the patch above plus some documentation in the NEWS and the manual.

2015-09-06 23:33 GMT+01:00 Stefan Monnier <monnier <at> iro.umontreal.ca>:
>>> That said, this change would seem to be an issue for anyone who is
>>> performing a partial initialisation in their init file (for specific
>>> packages), and then depending on the default initialisation to deal
>>> with the remainder, post-init.
>>>
>>> I can only imagine that's a very small proportion of users indeed,
>>> but I presume the scenario ought to be considered (even if only for
>>> the purposes of documenting it in NEWS).
>
>> Yes, they'll have to add (setq package-enable-at-startup t) after
>> calling initialize. That should definitely go in the NEWS.
>
> I have a hard time imagining many users doing that.  As a user, if I'm
> picky enough to try and do a partial initialization in my init file,
> I'll probably also want to do the final full initialization explicitly
> in my init file.

Now that it's pushed, I'm sure _someone_ will be affected by this and
will politely let us know. :)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.