GNU bug report logs - #65222
29.1; Packages initialize but package--initialize is nil

Previous Next

To reply to this bug, email your comments to 65222 AT debbugs.gnu.org.

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

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

From: dalanicolai <dalanicolai <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.1; Packages initialize but package--initialize is nil
Date: Fri, 11 Aug 2023 11:08:13 +0200

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

To reproduce the behavior we can not use 'emacs -Q', but otherwise the
bug is very simple. From a clean Emacs install simply install some
package. Now on (normal) startup (and `package-enable-at-startup` is t)
the packages get initialized before evaluating 'init.el' (indeed after
installing a single package, the package-alist wil be
populated). However, the value of `package--initialized` is still nil
(and I guess it should be t now).

This report is related to a subsequent bug report that I will send
directly after this one.


In GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.38,
 cairo version 1.17.8) of 2023-08-09 built on
 2a02-a45d-af56-1-666c-72af-583a-b92d.fixed6.kpn.net
Repository revision: 31cef9a4eac01fff5ff4fcb89d7e2b7815e93bad
Repository branch: HEAD
System Description: Fedora Linux 38 (Workstation Edition)

Configured using:
 'configure --with-tree-sitter --with-modules --with-cairo
 --with-native-compilation --with-json --with-pgtk'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LIBSELINUX LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PGTK PNG
RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER
XIM GTK3 ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  buffer-read-only: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message yank-media puny dired
dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068 epg-config
gnus-util text-property-search time-date mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils comp comp-cstr warnings
icons rx cl-extra help-mode info evil-autoloads package browse-url url
url-proxy url-privacy url-expand url-methods url-history url-cookie
generate-lisp-file url-domsuf url-util mailcap url-handlers url-parse
auth-source cl-seq eieio eieio-core cl-macs password-cache json subr-x
map byte-opt gv bytecomp byte-compile url-vars cl-loaddefs cl-lib rmc
iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode mwheel term/pgtk-win pgtk-win
term/common-win pgtk-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads dbusbind inotify dynamic-setting system-font-setting
font-render-setting cairo gtk pgtk multi-tty make-network-process
native-compile emacs)

Memory information:
((conses 16 112973 6385)
 (symbols 48 8729 0)
 (strings 32 30958 2801)
 (string-bytes 1 969890)
 (vectors 16 22797)
 (vector-slots 8 425568 11280)
 (floats 8 41 19)
 (intervals 56 346 0)
 (buffers 984 12))

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: dalanicolai <dalanicolai <at> gmail.com>, Philip Kaludercic <philipk <at> posteo.net>
Cc: 65222 <at> debbugs.gnu.org
Subject: Re: bug#65222: 29.1;
 Packages initialize but package--initialize is nil
Date: Sat, 19 Aug 2023 11:15:32 +0300

> From: dalanicolai <dalanicolai <at> gmail.com>
> Date: Fri, 11 Aug 2023 11:08:13 +0200
> 
> To reproduce the behavior we can not use 'emacs -Q', but otherwise the
> bug is very simple. From a clean Emacs install simply install some
> package. Now on (normal) startup (and `package-enable-at-startup` is t)
> the packages get initialized before evaluating 'init.el' (indeed after
> installing a single package, the package-alist wil be
> populated). However, the value of `package--initialized` is still nil
> (and I guess it should be t now).

Philip, any comments?

> This report is related to a subsequent bug report that I will send
> directly after this one.

Evidently, you never did, did you?

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

From: Philip Kaludercic <philipk <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 65222 <at> debbugs.gnu.org, dalanicolai <dalanicolai <at> gmail.com>
Subject: Re: bug#65222: 29.1; Packages initialize but package--initialize is
 nil
Date: Sat, 19 Aug 2023 09:02:55 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: dalanicolai <dalanicolai <at> gmail.com>
>> Date: Fri, 11 Aug 2023 11:08:13 +0200
>> 
>> To reproduce the behavior we can not use 'emacs -Q', but otherwise the
>> bug is very simple. From a clean Emacs install simply install some
>> package. Now on (normal) startup (and `package-enable-at-startup` is t)
>> the packages get initialized before evaluating 'init.el' (indeed after
>> installing a single package, the package-alist wil be
>> populated). However, the value of `package--initialized` is still nil
>> (and I guess it should be t now).
>
> Philip, any comments?

I can reproduce the issue, but this isn't an issue, since
`package-enable-at-startup' is related to the activation of packages at
startup, not the initialisation of package.el.  In startup.el we find

--8<---------------cut here---------------start------------->8---
;; If any package directory exists, initialize the package system.
  (and user-init-file
       package-enable-at-startup
       (not (bound-and-true-p package--activated))
       (catch 'package-dir-found
	 ...)
       (package-activate-all))
--8<---------------cut here---------------end--------------->8---

And it makes sense, when we consider the difference between
`package-activate-all' and `package-initialize'.  The former goes
through all available packages ensures they can be used, the former sets
up package.el-internal variables in addition to what
`package-activate-all' does, which is not necessary at startup if we
just want the packages to be made available for the user.

So south I understand the confusion, I believe the behaviour is correct.
What we could do is to extend the documentation at some places to avoid
this confusion in the future.

>> This report is related to a subsequent bug report that I will send
>> directly after this one.
>
> Evidently, you never did, did you?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: 65222 <at> debbugs.gnu.org, dalanicolai <at> gmail.com
Subject: Re: bug#65222: 29.1; Packages initialize but package--initialize is
 nil
Date: Sat, 19 Aug 2023 12:24:32 +0300

> From: Philip Kaludercic <philipk <at> posteo.net>
> Cc: dalanicolai <dalanicolai <at> gmail.com>,  65222 <at> debbugs.gnu.org
> Date: Sat, 19 Aug 2023 09:02:55 +0000
> 
> I can reproduce the issue, but this isn't an issue, since
> `package-enable-at-startup' is related to the activation of packages at
> startup, not the initialisation of package.el.  In startup.el we find
> 
> --8<---------------cut here---------------start------------->8---
> ;; If any package directory exists, initialize the package system.
>   (and user-init-file
>        package-enable-at-startup
>        (not (bound-and-true-p package--activated))
>        (catch 'package-dir-found
> 	 ...)
>        (package-activate-all))
> --8<---------------cut here---------------end--------------->8---
> 
> And it makes sense, when we consider the difference between
> `package-activate-all' and `package-initialize'.  The former goes
> through all available packages ensures they can be used, the former sets
> up package.el-internal variables in addition to what
> `package-activate-all' does, which is not necessary at startup if we
> just want the packages to be made available for the user.
> 
> So south I understand the confusion, I believe the behaviour is correct.
> What we could do is to extend the documentation at some places to avoid
> this confusion in the future.

Please suggest documentation patches you think are in order, and
thanks.

Previous Next

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