Re: [Emacs-diffs] master 4449301: * etc/NEWS: Improve documentation of 'package-initialize'.

Re: [Emacs-diffs] master 4449301: * etc/NEWS: Improve documentation of 'package-initialize'.

[Stefan Monnier]

> +(when (version< emacs-version "27.1")
> +  (package-initialize))

That doesn't do the right thing with the current `master` (nor will it
with Emacs-27.1's pretest).

Maybe a better option is

    (when package-enable-at-startup
      (package-initialize))

or

    (unless package-activated-list
      (package-initialize))


-- Stefan

Re: [Emacs-diffs] master 4449301: * etc/NEWS: Improve documentation of 'package-initialize'.

[Stefan Kangas]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> > +(when (version< emacs-version "27.1")
> > +  (package-initialize))
>
> That doesn't do the right thing with the current `master` (nor will it
> with Emacs-27.1's pretest).

Good point, thanks.

> Maybe a better option is
>
>     (when package-enable-at-startup
>       (package-initialize))

Yes, that would work.  But I'm not sure I understand this variable in general.

It is a defcustom (a user option), but:

1. It's ineffective when set from the custom interface, since it has
to be in the early init file.  Right?

2. It is a user option, but gets set automatically by
package-initialize.  This makes it a bit confusing, because
describe-variable says:

package-enable-at-startup is a variable defined in ‘package.el’.
Its value is nil
Original value was t

I initially thought this meant *I* had changed it for some reason,
because that's usually what it means when Emacs reports that it has
changed, and then I was confused when I couldn't find out where.  Only
after a while did I understand that this is a user option that doubles
as a variable that tracks if the package system was initialized or
not.

Would this be better as a defvar instead?  Or should we introduce a
new variable to mean that we are already initialized?  I don't mean to
rehash old discussions here, so feel free to refer me to earlier
discussions if you've already had them.

> or
>
>     (unless package-activated-list
>       (package-initialize))

That could also work.  Do we prefer not to do this by version?  For
example, my suggestion would probably have been:

(unless (< emacs-major-version 27)
  (package-initialize))

Best regards,
Stefan Kangas

Re: [Emacs-diffs] master 4449301: * etc/NEWS: Improve documentation of 'package-initialize'.

[Stefan Monnier]

> It is a defcustom (a user option), but:
> 1. It's ineffective when set from the custom interface, since it has
> to be in the early init file.  Right?

I guess it can still be effective if you load your custom-file from
early-init.el, but indeed it's rather unlikely to be effective in
Emacs≥27.

> 2. It is a user option, but gets set automatically by
> package-initialize.  This makes it a bit confusing, because
> describe-variable says:

Indeed, and this problem already existed before.

> Would this be better as a defvar instead?

I think you're right.


        Stefan

Re: [Emacs-diffs] master 4449301: * etc/NEWS: Improve documentation of 'package-initialize'.

[Stefan Kangas]

Stefan Kangas <stefankangas@gmail.com> writes:

> That could also work.  Do we prefer not to do this by version?  For
> example, my suggestion would probably have been:
>
> (unless (< emacs-major-version 27)
>   (package-initialize))

I've now pushed this version to master.

Best regards,
Stefan Kangas

Re: [Emacs-diffs] master 4449301: * etc/NEWS: Improve documentation of 'package-initialize'.

[Stefan Kangas]

[-- Attachment #1: Type: text/plain, Size: 1367 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> > It is a defcustom (a user option), but:
> > 1. It's ineffective when set from the custom interface, since it has
> > to be in the early init file.  Right?
>
> I guess it can still be effective if you load your custom-file from
> early-init.el, but indeed it's rather unlikely to be effective in
> Emacs≥27.

My guess would be that this will continue to be an unusual setup.

> > 2. It is a user option, but gets set automatically by
> > package-initialize.  This makes it a bit confusing, because
> > describe-variable says:
>
> Indeed, and this problem already existed before.
>
> > Would this be better as a defvar instead?
>
> I think you're right.

I started looking into package-enabe-at-startup, and of course the
above reasoning goes for package-load-list and package-user-dir; that
is, setting them via customize has no effect.  I see two alternatives:

1. Make sure that you can set all three via customize.
2. Make all three into defvars.

I'm not sure if option 1 is either practical or clean, so I'd lean
towards option 2, I think.  I'd be interested to hear what other
people think about it.

Meanwhile, the attached patch makes us not change the value of
package-enable-at-startup by introducing a new variable.  Any
comments?

Best regards,
Stefan Kangas

[-- Attachment #2: package-init.diff --]
[-- Type: text/x-patch, Size: 2595 bytes --]

diff --git a/doc/lispref/package.texi b/doc/lispref/package.texi
index 236855bdf8..a8a136f187 100644
--- a/doc/lispref/package.texi
+++ b/doc/lispref/package.texi
@@ -109,7 +109,7 @@ Packaging Basics
 @code{package-activate-all} to make installed packages available to the
 current session.  This is done after loading the early init file, but
 before loading the regular init file (@pxref{Startup Summary}).
-Packages are not automatically made available if the user option
+Packages are not automatically made available if the variable
 @code{package-enable-at-startup} is set to @code{nil} in the early
 init file.
 
diff --git a/etc/NEWS b/etc/NEWS
index 033cb48978..fa681f3f47 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -191,6 +191,9 @@ it won't work right without some adjustment:
   does not need to pay attention to 'package-load-list' or
   'package-user-dir' any more.
 
+The value of 'package-enable-at-startup' can no longer be changed
+using customize.
+
 ---
 ** Emacs now notifies systemd when startup finishes or shutdown begins.
 Units that are ordered after 'emacs.service' will only be started
diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el
index 539b236b63..2885b2c194 100644
--- a/lisp/emacs-lisp/package.el
+++ b/lisp/emacs-lisp/package.el
@@ -162,20 +162,23 @@ package
 ;;; Customization options
 
 ;;;###autoload
-(defcustom package-enable-at-startup t
+(defvar package-enable-at-startup t
   "Whether to make installed packages available when Emacs starts.
 If non-nil, packages are made available before reading the init
 file (but after reading the early init file).  This means that if
-you wish to set this variable, you must do so in the early init
-file.  Regardless of the value of this variable, packages are not
-made available if `user-init-file' is nil (e.g. Emacs was started
-with \"-q\").
+you wish to set this variable to nil, you must do that in the
+early init file.  See Info node `(emacs) Early Init File'.
+
+Note that the package system will automatically set this variable
+to nil when the package system is initialized.
+
+Regardless of the value of this variable, packages are not made
+available if `user-init-file' is nil (e.g. Emacs was started with
+\"-q\").
 
 Even if the value is nil, you can type \\[package-initialize] to
 make installed packages available at any time, or you can
-call (package-initialize) in your init-file."
-  :type 'boolean
-  :version "24.1")
+call (package-initialize) in your init-file.")
 
 (defcustom package-load-list '(all)
   "List of packages for `package-initialize' to make available.

Re: [Emacs-diffs] master 4449301: * etc/NEWS: Improve documentation of 'package-initialize'.

[Stefan Monnier]

> I started looking into package-enabe-at-startup, and of course the
> above reasoning goes for package-load-list and package-user-dir; that
> is, setting them via customize has no effect.

Yes and no: you can set `package-load-list` and `package-user-dir` in
your .emacs (and/or via customize) in order to affect the place where
packages are later installed and also in order to affect a subsequent
manual package-activate-all.

Currently, this requires setting (setq package-alist nil) by hand to
force reloading the package descriptors, but my hope is that we can
improve this in the future (e.g. with a :setter placed on those vars so
that package-activate-all is called again when they're modified via
custom).

Also, a "late-setting" of `package-load-list` (e.g. when set via
customize) will still work if you use `package-quickstart`.

> Meanwhile, the attached patch makes us not change the value of
> package-enable-at-startup by introducing a new variable.  Any
> comments?

The patch looks OK to me,


        Stefan

Re: [Emacs-diffs] master 4449301: * etc/NEWS: Improve documentation of 'package-initialize'.

[Stefan Kangas]

[-- Attachment #1: Type: text/plain, Size: 1515 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> > I started looking into package-enabe-at-startup, and of course the
> > above reasoning goes for package-load-list and package-user-dir; that
> > is, setting them via customize has no effect.
>
> Yes and no: you can set `package-load-list` and `package-user-dir` in
> your .emacs (and/or via customize) in order to affect the place where
> packages are later installed and also in order to affect a subsequent
> manual package-activate-all.
>
> Currently, this requires setting (setq package-alist nil) by hand to
> force reloading the package descriptors, but my hope is that we can
> improve this in the future (e.g. with a :setter placed on those vars so
> that package-activate-all is called again when they're modified via
> custom).

OK, thanks for explaining that.  I have attached a patch which changes
package-enable-at-startup into a defvar for now.

I've also added documentation to package-load-list and
package-user-dir to explain the above quirks.

Any comments?

> Also, a "late-setting" of `package-load-list` (e.g. when set via
> customize) will still work if you use `package-quickstart`.

I have two questions here:

1. I can't find anything on package-quickstart in the user manual.  Is
that intentional?  Perhaps it would make sense to create a new node
"initialization of packages" which could describe all this.

2. Should package-quickstart have a :set attribute with a value of
'package-quickstart-refresh?

Best regards,
Stefan Kangas

[-- Attachment #2: 0001-Make-package-enable-at-startup-into-defvar.patch --]
[-- Type: text/x-patch, Size: 4611 bytes --]

From 398ca928da1ff9e400836a365c4482949e03cea1 Mon Sep 17 00:00:00 2001
From: Stefan Kangas <stefankangas@gmail.com>
Date: Sat, 2 Nov 2019 06:46:09 +0100
Subject: [PATCH] Make package-enable-at-startup into defvar

* lisp/emacs-lisp/package.el (package-enable-at-startup): Change
from defcustom to defvar, since this has to be set in the early init
file (that is, normally before custom has been loaded).
* doc/lispref/package.texi (Packaging Basics): Document it.
* etc/NEWS (XDG_CONFIG_HOME): Announce it.

* lisp/emacs-lisp/package.el (package-load-list)
(package-user-dir): Doc fix to explain how to make them take effect
during startup.
---
 doc/lispref/package.texi   |  2 +-
 etc/NEWS                   |  3 +++
 lisp/emacs-lisp/package.el | 28 ++++++++++++++++++----------
 3 files changed, 22 insertions(+), 11 deletions(-)

diff --git a/doc/lispref/package.texi b/doc/lispref/package.texi
index 236855bdf8..a8a136f187 100644
--- a/doc/lispref/package.texi
+++ b/doc/lispref/package.texi
@@ -109,7 +109,7 @@ Packaging Basics
 @code{package-activate-all} to make installed packages available to the
 current session.  This is done after loading the early init file, but
 before loading the regular init file (@pxref{Startup Summary}).
-Packages are not automatically made available if the user option
+Packages are not automatically made available if the variable
 @code{package-enable-at-startup} is set to @code{nil} in the early
 init file.
 
diff --git a/etc/NEWS b/etc/NEWS
index 4134f7bb5f..48c66d7557 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -191,6 +191,9 @@ it won't work right without some adjustment:
   does not need to pay attention to 'package-load-list' or
   'package-user-dir' any more.
 
+The value of 'package-enable-at-startup' can no longer be changed
+using customize.  You have to set it manually in your early init file.
+
 ---
 ** Emacs now notifies systemd when startup finishes or shutdown begins.
 Units that are ordered after 'emacs.service' will only be started
diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el
index 6b75ecf783..f1835a424f 100644
--- a/lisp/emacs-lisp/package.el
+++ b/lisp/emacs-lisp/package.el
@@ -162,20 +162,20 @@ package
 ;;; Customization options
 
 ;;;###autoload
-(defcustom package-enable-at-startup t
+(defvar package-enable-at-startup t
   "Whether to make installed packages available when Emacs starts.
 If non-nil, packages are made available before reading the init
 file (but after reading the early init file).  This means that if
-you wish to set this variable, you must do so in the early init
-file.  Regardless of the value of this variable, packages are not
-made available if `user-init-file' is nil (e.g. Emacs was started
-with \"-q\").
+you wish to set this variable to nil, you must do that in the
+early init file.  See Info node `(emacs) Early Init File'.
+
+Regardless of the value of this variable, packages are not made
+available if `user-init-file' is nil (e.g. Emacs was started with
+\"-q\").
 
 Even if the value is nil, you can type \\[package-initialize] to
 make installed packages available at any time, or you can
-call (package-initialize) in your init-file."
-  :type 'boolean
-  :version "24.1")
+call (package-initialize) in your init-file.")
 
 (defcustom package-load-list '(all)
   "List of packages for `package-initialize' to make available.
@@ -190,7 +190,11 @@ package-load-list
 If VERSION is a string, only that version is ever made available.
  Any other version, even if newer, is silently ignored.
  Hence, the package is \"held\" at that version.
-If VERSION is nil, the package is not made available (it is \"disabled\")."
+If VERSION is nil, the package is not made available (it is \"disabled\").
+
+If you want this to take effect during the automatic package
+activation when Emacs starts, you have to set this variable in
+the early init file.  See Info node `(emacs) Early Init File'."
   :type '(repeat (choice (const all)
                          (list :tag "Specific package"
                                (symbol :tag "Package name")
@@ -293,7 +297,11 @@ package-user-dir
   "Directory containing the user's Emacs Lisp packages.
 The directory name should be absolute.
 Apart from this directory, Emacs also looks for system-wide
-packages in `package-directory-list'."
+packages in `package-directory-list'.
+
+If you want this to take effect during the automatic package
+activation when Emacs starts, you have to set this variable in
+the early init file.  See Info node `(emacs) Early Init File'."
   :type 'directory
   :risky t
   :version "24.1")
-- 
2.20.1

Re: [Emacs-diffs] master 4449301: * etc/NEWS: Improve documentation of 'package-initialize'.

[Stefan Monnier]

>> Currently, this requires setting (setq package-alist nil) by hand to
>> force reloading the package descriptors, but my hope is that we can
>> improve this in the future (e.g. with a :setter placed on those vars so
>> that package-activate-all is called again when they're modified via
>> custom).
>
> OK, thanks for explaining that.  I have attached a patch which changes
> package-enable-at-startup into a defvar for now.

I'm not sure if there's much harm in keeping it as a defcustom, so I'll
let someone else decide whether we should change it.  But if we do want
to change it, the patch looks OK to me in this respect.

> I've also added documentation to package-load-list and
> package-user-dir to explain the above quirks.

But this doesn't mention the fact that it still works if they use
`package-quickstart`.

>> Also, a "late-setting" of `package-load-list` (e.g. when set via
>> customize) will still work if you use `package-quickstart`.
> I have two questions here:
> 1. I can't find anything on package-quickstart in the user manual.
>    Is that intentional?

No.

> Perhaps it would make sense to create a new node "initialization of
> packages" which could describe all this.

Yes.  Maybe it should be a bit more general and include discussion of
customize settings.  IOW it could talk about dependencies and ordering
between package.el, custom.el, and "manual Elisp settings".

> 2. Should package-quickstart have a :set attribute with a value of
> 'package-quickstart-refresh?

I don't think so: the refresh should happen when the set of
installed/activated packages changes, whereas what you suggest would
cause a refresh to happen at every Emacs startup.

But I guess it does deserve a :set function, which should take care to
run `package-quickstart-refresh` if there's no quickstart file yet, or
to delete the quickstart file when set to nil (in both cases it should
maybe prompt the user before actually doing it?).


        Stefan

Re: [Emacs-diffs] master 4449301: * etc/NEWS: Improve documentation of 'package-initialize'.

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Mon, 11 Nov 2019 17:07:07 +0100
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> OK, thanks for explaining that.  I have attached a patch which changes
> package-enable-at-startup into a defvar for now.

I'm not sure I understand how grave are the problems with this
defcustom, but if they are, I'd prefer to add a :set function rather
than demoting a user option to a defvar.

Re: [Emacs-diffs] master 4449301: * etc/NEWS: Improve documentation of 'package-initialize'.

[Stefan Kangas]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I'm not sure if there's much harm in keeping it as a defcustom, so I'll
> let someone else decide whether we should change it.  But if we do want
> to change it, the patch looks OK to me in this respect.

OK, I must have misunderstood you above and believed you agreed that
it should be changed into a defvar.

Thinking a bit more about this, maybe we should add some general
machinery to specify that particular variables gets placed in the
early init file by default?  It could be a new property ':early-init
t', where Emacs inserts these particular variables into the early init
file instead of the init file.  Perhaps we could also add a new
variable 'custom-file-early' analogous to 'custom-file'.  Would that
make sense?

> > I've also added documentation to package-load-list and
> > package-user-dir to explain the above quirks.
>
> But this doesn't mention the fact that it still works if they use
> `package-quickstart`.

Please expect a new patch once I find the time to work on it.

> > Perhaps it would make sense to create a new node "initialization of
> > packages" which could describe all this.
>
> Yes.  Maybe it should be a bit more general and include discussion of
> customize settings.  IOW it could talk about dependencies and ordering
> between package.el, custom.el, and "manual Elisp settings".

Agreed, to make it more general was my thinking too.  I'll get to work
on such a section, which I'll add in packages.texi and name
"Initialization of Packages".

> > 2. Should package-quickstart have a :set attribute with a value of
> > 'package-quickstart-refresh?
>
> I don't think so: the refresh should happen when the set of
> installed/activated packages changes, whereas what you suggest would
> cause a refresh to happen at every Emacs startup.
>
> But I guess it does deserve a :set function, which should take care to
> run `package-quickstart-refresh` if there's no quickstart file yet, or
> to delete the quickstart file when set to nil (in both cases it should
> maybe prompt the user before actually doing it?).

Makes sense.  I could probably work on that too, if no one beats me to
it.  I haven't thought about the prompting, so I don't have an opinion
about that yet.

Best regards,
Stefan Kangas

Re: [Emacs-diffs] master 4449301: * etc/NEWS: Improve documentation of 'package-initialize'.

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> I'm not sure I understand how grave are the problems with this

The only problem is that it doesn't work.  :-)

To be more specific: When a user customizes this variable to nil, it
doesn't take effect.  As Stefan Monnier pointed out in this thread, it
*does* take effect iff the user loads the custom file from the early
init file.  I opined that this is probably not the most common use
pattern.

> defcustom, but if they are, I'd prefer to add a :set function rather
> than demoting a user option to a defvar.

OK, let's try that instead.  Please also see my other recent email in
this thread.

Best regards,
Stefan Kangas