bug#65222: 29.1; Packages initialize but package--initialize is nil

bug#65222: 29.1; Packages initialize but package--initialize is nil

[dalanicolai]

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

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))

[-- Attachment #2: Type: text/html, Size: 4326 bytes --]

bug#65222: 29.1; Packages initialize but package--initialize is nil

[Eli Zaretskii]

> From: dalanicolai <dalanicolai@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?

bug#65222: 29.1; Packages initialize but package--initialize is nil

[Philip Kaludercic]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: dalanicolai <dalanicolai@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?

bug#65222: 29.1; Packages initialize but package--initialize is nil

[Eli Zaretskii]

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: dalanicolai <dalanicolai@gmail.com>,  65222@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.