GNU bug report logs - #79188
31.0.50; Cannot build packages installed from VC

Previous Next

To reply to this bug, email your comments to 79188 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: Przemyslaw Kryger <pkryger <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; Cannot build packages installed from VC
Date: Thu, 07 Aug 2025 12:33:44 +0100

I am using package-vc to manage a few pakcages I maintain.  However, in Emacs
31 I observed a couple issues.

The first discrepancy with what used to happen on Emacs 30 is when a package is
installed from a custom location, no *.elc files are produced.  I don't know
what the expected behaviour should be here.

In addition to that when I attempt to rebuild such a package with
package-vc-rebuild it signals an error, which I believe shouldn't happen,
should it?  In this case no *.elc files have been produced nor updated.  Such a
workflow used to work on Emacs 30.

I observed this on a Emacs macport (from
https://github.com/jdtsmith/emacs-mac/tree/emacs-mac-gnu_master_exp), but the
issue is reproducible on master (68aaeb3519fd7f6176050e142f0dbc27e07992d2) as
well.

git clone https://github.com/pkryger/helm-projectile "${HOME}/tmp/helm-projectile"
emacs -Q

(require 'package)
(add-to-list 'package-archives '(melpa . "https://melpa.org/packages/"))
;; Just to avoid using existing elpa
(setq package-user-dir (expand-file-name "tmp/elpa" (getenv "HOME")))
(package-refresh-contents)
;; In my config I use hardcoded paths, but `use-package' needs a
;; string for `:load-path', so just for this sample
(let ((pkg-dir (expand-file-name "tmp/helm-projectile" (getenv "HOME"))))
  (eval
   `(use-package helm-projectile
      :vc t
      :load-path ,pkg-dir)))
      
;; At this point `helm-projectile' has been installed, but no *.elc files are
;; produced, which differs from Emacs 30.

(setq debug-on-error t)
M-x package-vc-rebuild RET helm-projectile RET

Which yields the following:

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  expand-file-name(nil)
  vc-file-getprop(nil vc-working-revision)
  vc-working-revision(nil)
  package-vc--unpack-1(#s(package-desc :name helm-projectile :version (1 3 1) :summary "Helm integration for Projectile" :reqs nil :kind vc :archive nil :dir "/Users/pkryger/tmp/elpa/helm-projectile/" :extras ((:commit . "2ecd3d85b7077f39bb2fefe2227cc46931d4b92b")) :signed nil) "/Users/pkryger/tmp/elpa/helm-projectile/")
  package-vc-rebuild(#s(package-desc :name helm-projectile :version (1 3 1) :summary "Helm integration for Projectile" :reqs nil :kind vc :archive nil :dir "/Users/pkryger/tmp/elpa/helm-projectile/" :extras ((:commit . "2ecd3d85b7077f39bb2fefe2227cc46931d4b92b")) :signed nil))
  funcall-interactively(package-vc-rebuild #s(package-desc :name helm-projectile :version (1 3 1) :summary "Helm integration for Projectile" :reqs nil :kind vc :archive nil :dir "/Users/pkryger/tmp/elpa/helm-projectile/" :extras ((:commit . "2ecd3d85b7077f39bb2fefe2227cc46931d4b92b")) :signed nil))
  call-interactively(package-vc-rebuild record nil)
  command-execute(package-vc-rebuild record)
  execute-extended-command(nil "package-vc-rebuild" "pack-v-re")
  funcall-interactively(execute-extended-command nil "package-vc-rebuild" "pack-v-re")
  call-interactively(execute-extended-command nil nil)
  command-execute(execute-extended-command)

Could these be introduced by  4226eb2b20408ba49787195bbc59bb0066c9c9e4?


In GNU Emacs 31.0.50 (build 1, aarch64-apple-darwin24.5.0, X toolkit,
 cairo version 1.18.4, Xaw3d scroll bars) of 2025-08-07 built on
 Przemyslaws-MacBook-Air.local
Repository revision: 68aaeb3519fd7f6176050e142f0dbc27e07992d2
Repository branch: master
System Description:  macOS 15.5

Configured using:
 'configure --without-ns --with-gnutls --with-modules
 --with-native-compilation=no --with-jpeg=ifavailable
 --with-gif=ifavailable --with-tiff=ifavailable CFLAGS=-O3'

Configured features:
ACL CAIRO FREETYPE GLIB GNUTLS GSETTINGS HARFBUZZ LCMS2 LIBXML2 MODULES
NOTIFY KQUEUE PDUMPER PNG RSVG SQLITE3 THREADS TOOLKIT_SCROLL_BARS
TREE_SITTER WEBP X11 XAW3D XDBE XIM XINERAMA XPM XRANDR LUCID ZLIB

Important settings:
  value of $LANG: en_GB.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  xterm-mouse-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  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
  font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-regexp-mode: 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:
/Users/pkryger/tmp/elpa/helm-4.0.4/helm-packages hides /Users/pkryger/tmp/elpa/helm-core-4.0.4/helm-packages
/Users/pkryger/tmp/elpa/helm-4.0.4/helm-x-icons hides /Users/pkryger/tmp/elpa/helm-core-4.0.4/helm-x-icons

Features:
(shadow sort mail-extr emacsbug use-package-ensure help-fns cl-print
debug backtrace find-func helm-projectile projectile helm-files
image-dired image-dired-tags image-dired-external image-dired-util
image-mode exif filenotify dired-x ffap tramp rx trampver
tramp-integration tramp-message tramp-compat shell pcomplete parse-time
iso8601 tramp-loaddefs helm-tags helm-buffers helm-x-icons helm-occur
helm-grep helm-regexp format-spec helm-utils helm-locate helm-help helm
helm-types helm-global-bindings helm-easymenu edmacro kmacro helm-core
helm-source helm-multi-match helm-lib cus-edit pp cus-start cus-load
wid-edit helm-projectile-autoloads helm-autoloads helm-core-autoloads
vc-git diff-mode track-changes files-x wfnames-autoloads smtpmail
dired-async dired-aux async-bytecomp async bug-reference async-autoloads
project skeleton ibuf-macs pcase find-dired grep ibuf-ext ibuffer
ibuffer-loaddefs thingatpt compile comint ansi-osc ansi-color ring
projectile-autoloads easy-mmode loaddefs-gen radix-tree tar-mode
arc-mode archive-mode package-vc vc vc-dispatcher lisp-mnt cl-extra
help-mode use-package-core finder-inf mm-archive message sendmail
yank-media dired dired-loaddefs rfc822 mml mml-sec epa derived gnus-util
text-property-search mailabbrev gmm-utils mailheader mm-decode mm-bodies
mm-encode mail-utils gnutls network-stream url-cache warnings url-http
url-auth mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums
mail-prsvr url-gw nsm puny epg rfc6068 epg-config package browse-url xdg
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 icons password-cache json
map url-vars time-date subr-x cl-loaddefs cl-lib xt-mouse term/xterm
xterm byte-opt gv bytecomp byte-compile rmc iso-transl tooltip cconv
eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode mwheel term/x-win x-win term/common-win x-dnd touch-screen
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 kqueue
lcms2 dynamic-setting system-font-setting font-render-setting cairo
x-toolkit x multi-tty move-toolbar make-network-process tty-child-frames
emacs)

Memory information:
((conses 16 349318 58285) (symbols 48 22829 1) (strings 32 68024 3090)
 (string-bytes 1 2006739) (vectors 16 34746)
 (vector-slots 8 661887 21587) (floats 8 132 421)
 (intervals 56 1420 25) (buffers 1064 20))

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

From: Philip Kaludercic <philipk <at> posteo.net>
To: Przemyslaw Kryger <pkryger <at> gmail.com>
Cc: 79188 <at> debbugs.gnu.org
Subject: Re: bug#79188: 31.0.50; Cannot build packages installed from VC
Date: Thu, 07 Aug 2025 12:55:43 +0000

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

Przemyslaw Kryger <pkryger <at> gmail.com> writes:

> I am using package-vc to manage a few pakcages I maintain.  However, in Emacs
> 31 I observed a couple issues.
>
> The first discrepancy with what used to happen on Emacs 30 is when a package is
> installed from a custom location, no *.elc files are produced.  I don't know
> what the expected behaviour should be here.
>
> In addition to that when I attempt to rebuild such a package with
> package-vc-rebuild it signals an error, which I believe shouldn't happen,
> should it?  In this case no *.elc files have been produced nor updated.  Such a
> workflow used to work on Emacs 30.

Both of these shouldn't happen.

> I observed this on a Emacs macport (from
> https://github.com/jdtsmith/emacs-mac/tree/emacs-mac-gnu_master_exp), but the
> issue is reproducible on master (68aaeb3519fd7f6176050e142f0dbc27e07992d2) as
> well.
>
> git clone https://github.com/pkryger/helm-projectile "${HOME}/tmp/helm-projectile"
> emacs -Q
>
> (require 'package)
> (add-to-list 'package-archives '(melpa . "https://melpa.org/packages/"))
                                   ^
                                   this should be a string!

> ;; Just to avoid using existing elpa
> (setq package-user-dir (expand-file-name "tmp/elpa" (getenv "HOME")))

(Unrelated, but is there a reason you aren't doing (expand-file-name
"~/tmp/elpa")?)

> (package-refresh-contents)
> ;; In my config I use hardcoded paths, but `use-package' needs a
> ;; string for `:load-path', so just for this sample
> (let ((pkg-dir (expand-file-name "tmp/helm-projectile" (getenv "HOME"))))
>   (eval
>    `(use-package helm-projectile
>       :vc t
>       :load-path ,pkg-dir)))

For posterity, this expands to

--8<---------------cut here---------------start------------->8---
(progn
  (eval-and-compile (add-to-list 'load-path "/tmp/helm-projectile/"))
  (use-package-vc-install '(helm-projectile) "/tmp/helm-projectile/")
  (defvar use-package--warning0
    #'(lambda (keyword err)
	(let
	    ((msg
	      (format "%s/%s: %s" 'helm-projectile keyword
		      (error-message-string err))))
	  (display-warning 'use-package msg :error))))
  (condition-case-unless-debug err
      (if (not (require 'helm-projectile nil t))
	  (display-warning 'use-package
			   (format "Cannot load %s" 'helm-projectile)
			   :error))
    (error (funcall use-package--warning0 :catch err))))
--8<---------------cut here---------------end--------------->8---

which for us means that we are interested in

(use-package-vc-install '(helm-projectile) "/tmp/helm-projectile/")

which in turn would invoke

(package-vc-install-from-checkout "/tmp/helm-projectile/" "helm-projectile")

>       
> ;; At this point `helm-projectile' has been installed, but no *.elc files are
> ;; produced, which differs from Emacs 30.
>
> (setq debug-on-error t)
> M-x package-vc-rebuild RET helm-projectile RET
>
> Which yields the following:
>
> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>   expand-file-name(nil)
>   vc-file-getprop(nil vc-working-revision)
>   vc-working-revision(nil)
>   package-vc--unpack-1(#s(package-desc :name helm-projectile :version (1 3 1) :summary "Helm integration for Projectile" :reqs nil :kind vc :archive nil :dir "/Users/pkryger/tmp/elpa/helm-projectile/" :extras ((:commit . "2ecd3d85b7077f39bb2fefe2227cc46931d4b92b")) :signed nil) "/Users/pkryger/tmp/elpa/helm-projectile/")
>   package-vc-rebuild(#s(package-desc :name helm-projectile :version (1 3 1) :summary "Helm integration for Projectile" :reqs nil :kind vc :archive nil :dir "/Users/pkryger/tmp/elpa/helm-projectile/" :extras ((:commit . "2ecd3d85b7077f39bb2fefe2227cc46931d4b92b")) :signed nil))
>   funcall-interactively(package-vc-rebuild #s(package-desc :name helm-projectile :version (1 3 1) :summary "Helm integration for Projectile" :reqs nil :kind vc :archive nil :dir "/Users/pkryger/tmp/elpa/helm-projectile/" :extras ((:commit . "2ecd3d85b7077f39bb2fefe2227cc46931d4b92b")) :signed nil))
>   call-interactively(package-vc-rebuild record nil)
>   command-execute(package-vc-rebuild record)
>   execute-extended-command(nil "package-vc-rebuild" "pack-v-re")
>   funcall-interactively(execute-extended-command nil "package-vc-rebuild" "pack-v-re")
>   call-interactively(execute-extended-command nil nil)
>   command-execute(execute-extended-command)

I couldn't reproduce this stack trace :/  It seems like
`package-vc--main-file' returned nil.  Can you check what the function
returns, perhaps using edebug?

> Could these be introduced by  4226eb2b20408ba49787195bbc59bb0066c9c9e4?

That seems reasonable, but in that case we should be able to reproduce
the issue with a more simple example (especially one that doesn't involve
use-package, MELPA and missing dependencies).  I tried it out with a
local package I had lying around and I also noticed that we don't
byte-compile files anymore!

This should fix the first issue, but it probably won't change anything
about the latter:

[Message part 2 (text/x-patch, inline)]

diff --git a/lisp/package/package-vc.el b/lisp/package/package-vc.el
index db12c76133e..f2c7c460f6d 100644
--- a/lisp/package/package-vc.el
+++ b/lisp/package/package-vc.el
@@ -549,7 +549,14 @@ package-vc--unpack-1
         ;; FIXME: Compilation should be done as a separate, optional, step.
         ;; E.g. for multi-package installs, we should first install all packages
         ;; and then compile them.
-        (package--compile new-desc)
+        (package--compile
+         (if lisp-dir
+             ;; In case we are installing a package from a local
+             ;; checkout, we want to compile the checkout, not the
+             ;; redirection!
+             (package-desc-create :dir lisp-dir)
+          new-desc))
+
         (when package-native-compile
           (package--native-compile-async new-desc))
         ;; After compilation, load again any files loaded by

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

>
> In GNU Emacs 31.0.50 (build 1, aarch64-apple-darwin24.5.0, X toolkit,
>  cairo version 1.18.4, Xaw3d scroll bars) of 2025-08-07 built on
>  Przemyslaws-MacBook-Air.local
> Repository revision: 68aaeb3519fd7f6176050e142f0dbc27e07992d2
> Repository branch: master
> System Description:  macOS 15.5
>
> Configured using:
>  'configure --without-ns --with-gnutls --with-modules
>  --with-native-compilation=no --with-jpeg=ifavailable
>  --with-gif=ifavailable --with-tiff=ifavailable CFLAGS=-O3'
>
> Configured features:
> ACL CAIRO FREETYPE GLIB GNUTLS GSETTINGS HARFBUZZ LCMS2 LIBXML2 MODULES
> NOTIFY KQUEUE PDUMPER PNG RSVG SQLITE3 THREADS TOOLKIT_SCROLL_BARS
> TREE_SITTER WEBP X11 XAW3D XDBE XIM XINERAMA XPM XRANDR LUCID ZLIB
>
> Important settings:
>   value of $LANG: en_GB.UTF-8
>   locale-coding-system: utf-8-unix
>
> Major mode: Lisp Interaction
>
> Minor modes in effect:
>   xterm-mouse-mode: t
>   tooltip-mode: t
>   global-eldoc-mode: t
>   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
>   font-lock-mode: t
>   blink-cursor-mode: t
>   minibuffer-regexp-mode: 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:
> /Users/pkryger/tmp/elpa/helm-4.0.4/helm-packages hides /Users/pkryger/tmp/elpa/helm-core-4.0.4/helm-packages
> /Users/pkryger/tmp/elpa/helm-4.0.4/helm-x-icons hides /Users/pkryger/tmp/elpa/helm-core-4.0.4/helm-x-icons
>
> Features:
> (shadow sort mail-extr emacsbug use-package-ensure help-fns cl-print
> debug backtrace find-func helm-projectile projectile helm-files
> image-dired image-dired-tags image-dired-external image-dired-util
> image-mode exif filenotify dired-x ffap tramp rx trampver
> tramp-integration tramp-message tramp-compat shell pcomplete parse-time
> iso8601 tramp-loaddefs helm-tags helm-buffers helm-x-icons helm-occur
> helm-grep helm-regexp format-spec helm-utils helm-locate helm-help helm
> helm-types helm-global-bindings helm-easymenu edmacro kmacro helm-core
> helm-source helm-multi-match helm-lib cus-edit pp cus-start cus-load
> wid-edit helm-projectile-autoloads helm-autoloads helm-core-autoloads
> vc-git diff-mode track-changes files-x wfnames-autoloads smtpmail
> dired-async dired-aux async-bytecomp async bug-reference async-autoloads
> project skeleton ibuf-macs pcase find-dired grep ibuf-ext ibuffer
> ibuffer-loaddefs thingatpt compile comint ansi-osc ansi-color ring
> projectile-autoloads easy-mmode loaddefs-gen radix-tree tar-mode
> arc-mode archive-mode package-vc vc vc-dispatcher lisp-mnt cl-extra
> help-mode use-package-core finder-inf mm-archive message sendmail
> yank-media dired dired-loaddefs rfc822 mml mml-sec epa derived gnus-util
> text-property-search mailabbrev gmm-utils mailheader mm-decode mm-bodies
> mm-encode mail-utils gnutls network-stream url-cache warnings url-http
> url-auth mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums
> mail-prsvr url-gw nsm puny epg rfc6068 epg-config package browse-url xdg
> 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 icons password-cache json
> map url-vars time-date subr-x cl-loaddefs cl-lib xt-mouse term/xterm
> xterm byte-opt gv bytecomp byte-compile rmc iso-transl tooltip cconv
> eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
> elisp-mode mwheel term/x-win x-win term/common-win x-dnd touch-screen
> 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 kqueue
> lcms2 dynamic-setting system-font-setting font-render-setting cairo
> x-toolkit x multi-tty move-toolbar make-network-process tty-child-frames
> emacs)
>
> Memory information:
> ((conses 16 349318 58285) (symbols 48 22829 1) (strings 32 68024 3090)
>  (string-bytes 1 2006739) (vectors 16 34746)
>  (vector-slots 8 661887 21587) (floats 8 132 421)
>  (intervals 56 1420 25) (buffers 1064 20))
>
>

-- 
Philip Kaludercic

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

From: Przemysław Kryger <pkryger <at> gmail.com>
Cc: 79188 <at> debbugs.gnu.org
Subject: Fwd: bug#79188: 31.0.50; Cannot build packages installed from VC
Date: Thu, 7 Aug 2025 17:53:00 +0100

Forwarding - missed the debbugs
---------- Forwarded message ---------
From: Przemysław Kryger <pkryger <at> gmail.com>
Date: Thu, 7 Aug 2025 at 17:46
Subject: Re: bug#79188: 31.0.50; Cannot build packages installed from VC
To: Philip Kaludercic <philipk <at> posteo.net>


Philip Kaludercic <philipk <at> posteo.net> writes:

> Przemyslaw Kryger <pkryger <at> gmail.com> writes:
>
>> I am using package-vc to manage a few pakcages I maintain.  However, in Emacs
>> 31 I observed a couple issues.
>>
>> The first discrepancy with what used to happen on Emacs 30 is when a package is
>> installed from a custom location, no *.elc files are produced.  I don't know
>> what the expected behaviour should be here.
>>
>> In addition to that when I attempt to rebuild such a package with
>> package-vc-rebuild it signals an error, which I believe shouldn't happen,
>> should it?  In this case no *.elc files have been produced nor updated.  Such a
>> workflow used to work on Emacs 30.
>
> Both of these shouldn't happen.

Thank you for taking a look and for confirmation.

[...]
>> (add-to-list 'package-archives '(melpa . "https://melpa.org/packages/"))
>                                    ^
>                                    this should be a string!

Thanks for pointing out.  It seems to work regardless.

>> ;; Just to avoid using existing elpa
>> (setq package-user-dir (expand-file-name "tmp/elpa" (getenv "HOME")))
>
> (Unrelated, but is there a reason you aren't doing (expand-file-name
> "~/tmp/elpa")?)

No, not really.

[...]
>> (let ((pkg-dir (expand-file-name "tmp/helm-projectile" (getenv "HOME"))))
>>   (eval
>>    `(use-package helm-projectile
>>       :vc t
>>       :load-path ,pkg-dir)))
>
> For posterity, this expands to
>
[...]
> which in turn would invoke
>
> (package-vc-install-from-checkout "/tmp/helm-projectile/" "helm-projectile")

I think I reached very similar same conclusion.  When I changed the
installation bit to:

(package-vc-install-from-checkout (expand-file-name "~/tmp/helm-projectile")
                                  "helm-projectile")

both issues still reproduce.  That is after installation there are no
*.elc files to be found and an attempt to rebuild the package with
`package-vc-rebuild' yielded the same stack.

[...]

>> Which yields the following:
>>
>> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>>   expand-file-name(nil)
>>   vc-file-getprop(nil vc-working-revision)
>>   vc-working-revision(nil)
>>   package-vc--unpack-1(#s(package-desc :name helm-projectile :version (1 3 1)
>> :summary "Helm integration for Projectile" :reqs nil :kind vc :archive nil
>> :dir "/Users/pkryger/tmp/elpa/helm-projectile/" :extras ((:commit
>> . "2ecd3d85b7077f39bb2fefe2227cc46931d4b92b")) :signed nil)
>> "/Users/pkryger/tmp/elpa/helm-projectile/")
>>   package-vc-rebuild(#s(package-desc :name helm-projectile :version (1 3 1) :summary "Helm integration for Projectile" :reqs nil :kind vc :archive nil :dir "/Users/pkryger/tmp/elpa/helm-projectile/" :extras ((:commit . "2ecd3d85b7077f39bb2fefe2227cc46931d4b92b")) :signed nil))
>>   funcall-interactively(package-vc-rebuild #s(package-desc :name helm-projectile :version (1 3 1) :summary "Helm integration for Projectile" :reqs nil :kind vc :archive nil :dir "/Users/pkryger/tmp/elpa/helm-projectile/" :extras ((:commit . "2ecd3d85b7077f39bb2fefe2227cc46931d4b92b")) :signed nil))
>>   call-interactively(package-vc-rebuild record nil)
>>   command-execute(package-vc-rebuild record)
>>   execute-extended-command(nil "package-vc-rebuild" "pack-v-re")
>>   funcall-interactively(execute-extended-command nil "package-vc-rebuild" "pack-v-re")
>>   call-interactively(execute-extended-command nil nil)
>>   command-execute(execute-extended-command)
>
> I couldn't reproduce this stack trace :/  It seems like
> `package-vc--main-file' returned nil.  Can you check what the function
> returns, perhaps using edebug?

I run `package-vc-rebuild' and indeed the `package-vc--main-file' yields
is nil in Edebug instrumented `package-vc--unpack-file-1'.

>> Could these be introduced by  4226eb2b20408ba49787195bbc59bb0066c9c9e4?
>
> That seems reasonable, but in that case we should be able to reproduce
> the issue with a more simple example (especially one that doesn't involve
> use-package, MELPA and missing dependencies).  I tried it out with a
> local package I had lying around and I also noticed that we don't
> byte-compile files anymore!
>
> This should fix the first issue, but it probably won't change anything
> about the latter:
>
> diff --git a/lisp/package/package-vc.el b/lisp/package/package-vc.el
> index db12c76133e..f2c7c460f6d 100644
> --- a/lisp/package/package-vc.el
> +++ b/lisp/package/package-vc.el
> @@ -549,7 +549,14 @@ package-vc--unpack-1
>          ;; FIXME: Compilation should be done as a separate, optional, step.
>          ;; E.g. for multi-package installs, we should first install all packages
>          ;; and then compile them.
> -        (package--compile new-desc)
> +        (package--compile
> +         (if lisp-dir
> +             ;; In case we are installing a package from a local
> +             ;; checkout, we want to compile the checkout, not the
> +             ;; redirection!
> +             (package-desc-create :dir lisp-dir)
> +          new-desc))
> +
>          (when package-native-compile
>            (package--native-compile-async new-desc))
>          ;; After compilation, load again any files loaded by
>

I don't have lisp/pakcage/package-vc.el, but I changed the file name to
lisp/emacs-lisp/packgage-vc.el and the patch applied cleanly.

Below I will use:
- "package source directory" to denote where package
   resides (i.e., ${HOME}/tmp/helm-projectile)
- "package install directory" to denote where package is installed,
  i.e. a result of:

(expand-file-name "helm-projectile" package-user-dir)

After I repeated the experiment the package installed with just
`package-vc-install-from-checkout' (as described above) and
helm-projectile.elc file has been produced into package source
directory.

Not sure if it is important but at this point my `load-path' has only
the package source directory and no package install directory.  I wonder
how the helm-projectile-autoloads.el that has been produced into the
package install directory is going to take part further (in the same and
in a future Emacs session).  Will both directories eventually end up in
the `load-path'?

I removed the compiled helm-projectile.elc from package source directory
and executed:

M-x package-vc-rebuild RET helm-projectile RET

which yield familiar stack trace.

The funny thing is that this time around, the package source directory
had no *.elc files created.  However, the package install directory
contained helm-projectile-autoloads.elc [sic!].

I run the patched `package-vc--unpack-1' and this time `lisp-dir' was nil
(in l.550, where patch has been applied) and 'package-desc--main-file'
yielded nil again.

A question: shouldn't the newly generated *.elc files be put in package
install directory, just like the (non compiled) autoloads file is?  In
my - very naïve - view this would not only remove burden of doubling
`load-path' entries (will that happen) but would also allow for a
complete separation of compiled files between multiple Emacs versions
coexisting on the same machine and reusing the same package source
directories.

Last but not least.  When stepping through `package-vc--unpack-1' under
Edebug for `package-vc-rebuild' I noticed that when it scans for
dependencies it examines files in package install directory.  However,
these files (i.e., helm-projectile-pkg.el and
helm-projectile-autoloads.el) define no dependencies.  Shouldn't the
scan happen for files in the package source directory? I think this was
what Emacs 30 did, due to symlink.

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

From: Przemysław Kryger <pkryger <at> gmail.com>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: 79188 <at> debbugs.gnu.org
Subject: Re: bug#79188: 31.0.50; Cannot build packages installed from VC
Date: Fri, 08 Aug 2025 12:07:14 +0100

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

tags 79188 + patch
quit

Przemysław Kryger <pkryger <at> gmail.com> writes:
>> That seems reasonable, but in that case we should be able to reproduce
>> the issue with a more simple example (especially one that doesn't involve
>> use-package, MELPA and missing dependencies). [...]

I managed to reproduce the issue with
https://github.com/pkryger/basic-stats.el, which has no extra
dependencies.  I could reproduce all the issues I described in previous
message (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=79188#11).

In addition I noticed, that `package-vc-upgrade' doesn't work as
well. This one was trying to pull inside the package install directory,
i.e, under `packgage-user-dir'.

>> This should fix the first issue, but it probably won't change anything
>> about the latter:
>>
>> diff --git a/lisp/package/package-vc.el b/lisp/package/package-vc.el
>> index db12c76133e..f2c7c460f6d 100644
>> --- a/lisp/package/package-vc.el
>> +++ b/lisp/package/package-vc.el
>> @@ -549,7 +549,14 @@ package-vc--unpack-1
>>          ;; FIXME: Compilation should be done as a separate, optional, st=
> ep.
>>          ;; E.g. for multi-package installs, we should first install all =
> packages
>>          ;; and then compile them.
>> -        (package--compile new-desc)
>> +        (package--compile
>> +         (if lisp-dir
>> +             ;; In case we are installing a package from a local
>> +             ;; checkout, we want to compile the checkout, not the
>> +             ;; redirection!
>> +             (package-desc-create :dir lisp-dir)
>> +          new-desc))
>> +
>>          (when package-native-compile
>>            (package--native-compile-async new-desc))
>>          ;; After compilation, load again any files loaded by
>>
>
> I don't have lisp/pakcage/package-vc.el, but I changed the file name to
> lisp/emacs-lisp/packgage-vc.el and the patch applied cleanly.
>
> [...]
>
> After I repeated the experiment the package installed with just
> `package-vc-install-from-checkout' (as described above) and
> helm-projectile.elc file has been produced into package source
> directory.

Based on that work I developed a new patch.  With both of the attached
patches applied I was able to run `package-vc-rebuild' and
`package-vc-reinstall' on the aforementioned package basic-stats and
observed that *.elc files were created in the source directory (i.e.,
the local checkout) and not in package install directory.

> A question: shouldn't the newly generated *.elc files be put in
> package install directory, just like the (non compiled) autoloads file
> is?  In my - very na=C3=AFve - view this would not only remove burden
> of doubling `load-path' entries (will that happen) but would also
> allow for a complete separation of compiled files between multiple
> Emacs versions coexisting on the same machine and reusing the same
> package source directories.

While the patch attached fixes basic workflows, I wonder idea of having
*.elc in a package install directory is worth exploring.  Would that
affect other functionalities?  For example `load' and `require' should
just work (provided the package install directory is in front of package
source directory in `load-pat'), but what will happen with
`find-library'/`locate-library'?  Are there any others?

[0001-Compile-file-in-local-checkout-directory.patch (text/plain, attachment)]

[0002-Store-local-checkout-directory-in-autoloads-indirect.patch (text/plain, attachment)]

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

From: Philip Kaludercic <philipk <at> posteo.net>
To: Przemysław Kryger <pkryger <at> gmail.com>
Cc: 79188 <at> debbugs.gnu.org
Subject: Re: bug#79188: 31.0.50; Cannot build packages installed from VC
Date: Sat, 09 Aug 2025 11:43:59 +0000

Przemysław Kryger <pkryger <at> gmail.com> writes:

> tags 79188 + patch
> quit
>
> Przemysław Kryger <pkryger <at> gmail.com> writes:
>>> That seems reasonable, but in that case we should be able to reproduce
>>> the issue with a more simple example (especially one that doesn't involve
>>> use-package, MELPA and missing dependencies). [...]
>
> I managed to reproduce the issue with
> https://github.com/pkryger/basic-stats.el, which has no extra
> dependencies.  I could reproduce all the issues I described in previous
> message (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=79188#11).
>
> In addition I noticed, that `package-vc-upgrade' doesn't work as
> well. This one was trying to pull inside the package install directory,
> i.e, under `packgage-user-dir'.
>
>>> This should fix the first issue, but it probably won't change anything
>>> about the latter:
>>>
>>> diff --git a/lisp/package/package-vc.el b/lisp/package/package-vc.el
>>> index db12c76133e..f2c7c460f6d 100644
>>> --- a/lisp/package/package-vc.el
>>> +++ b/lisp/package/package-vc.el
>>> @@ -549,7 +549,14 @@ package-vc--unpack-1
>>>          ;; FIXME: Compilation should be done as a separate, optional, st=
>> ep.
>>>          ;; E.g. for multi-package installs, we should first install all =
>> packages
>>>          ;; and then compile them.
>>> -        (package--compile new-desc)
>>> +        (package--compile
>>> +         (if lisp-dir
>>> +             ;; In case we are installing a package from a local
>>> +             ;; checkout, we want to compile the checkout, not the
>>> +             ;; redirection!
>>> +             (package-desc-create :dir lisp-dir)
>>> +          new-desc))
>>> +
>>>          (when package-native-compile
>>>            (package--native-compile-async new-desc))
>>>          ;; After compilation, load again any files loaded by
>>>
>>
>> I don't have lisp/pakcage/package-vc.el, but I changed the file name to
>> lisp/emacs-lisp/packgage-vc.el and the patch applied cleanly.
>>
>> [...]
>>
>> After I repeated the experiment the package installed with just
>> `package-vc-install-from-checkout' (as described above) and
>> helm-projectile.elc file has been produced into package source
>> directory.
>
> Based on that work I developed a new patch.  With both of the attached
> patches applied I was able to run `package-vc-rebuild' and
> `package-vc-reinstall' on the aforementioned package basic-stats and
> observed that *.elc files were created in the source directory (i.e.,
> the local checkout) and not in package install directory.

Thanks, I have some comments below.

>> A question: shouldn't the newly generated *.elc files be put in
>> package install directory, just like the (non compiled) autoloads file
>> is?  In my - very na=C3=AFve - view this would not only remove burden
>> of doubling `load-path' entries (will that happen) but would also
>> allow for a complete separation of compiled files between multiple
>> Emacs versions coexisting on the same machine and reusing the same
>> package source directories.
>
> While the patch attached fixes basic workflows, I wonder idea of having
> *.elc in a package install directory is worth exploring.  Would that
> affect other functionalities?  For example `load' and `require' should
> just work (provided the package install directory is in front of package
> source directory in `load-pat'), but what will happen with
> `find-library'/`locate-library'?  Are there any others?

By package install directory you mean the ~/.emacs.d/elpa/... directory
right?  I get the advantage of not having incompatible .elc versions but
I am not an expert when it comes the load-order questions.  I think we
should discuss this in a separate feature request and then ask someone
who knows more about that to avoid making clumsy mistakes.  Does that
sound OK?

> From 56fa1014b1f8f2eb7f6d87304c3f31604fed48ba Mon Sep 17 00:00:00 2001
> From: Philip Kaludercic <philipk <at> posteo.net>
> Date: Fri, 8 Aug 2025 11:43:24 +0100
> Subject: [PATCH 1/2] Compile file in local checkout directory
>
> This partially fixes bug#79188.

We usually reference bug numbers at the end of a commit message in
parentheses, but I can take care of that.

> * lisp/emacs-lisp/package-vc.el (package-vc--unpack-1): Compile package
>   in a local checkout directory when it is installed from such a
>   location, for example with `package-vc-install-from-checkout'.
> ---
>  lisp/emacs-lisp/package-vc.el | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/lisp/emacs-lisp/package-vc.el b/lisp/emacs-lisp/package-vc.el
> index 7433fce2d89..9e118c7af02 100644
> --- a/lisp/emacs-lisp/package-vc.el
> +++ b/lisp/emacs-lisp/package-vc.el
> @@ -546,7 +546,14 @@ package-vc--unpack-1
>          ;; FIXME: Compilation should be done as a separate, optional, step.
>          ;; E.g. for multi-package installs, we should first install all packages
>          ;; and then compile them.
> -        (package--compile new-desc)
> +        (package--compile
> +         (if lisp-dir
> +             ;; In case we are installing a package from a local
> +             ;; checkout, we want to compile the checkout, not the
> +             ;; redirection!
> +             (package-desc-create :dir lisp-dir)
> +          new-desc))
> +
>          (when package-native-compile
>            (package--native-compile-async new-desc))
>          ;; After compilation, load again any files loaded by
> -- 
> 2.50.1
>
>
> From 07596327df8bee5831003b62c811dd3fc53f2a88 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Przemys=C5=82aw=20Kryger?= <pkryger <at> gmail.com>
> Date: Fri, 8 Aug 2025 11:43:52 +0100
> Subject: [PATCH 2/2] Store local checkout directory in autoloads indirection
>
> * lisp/emacs-lisp/package-vc.el (package-vc--unpack-1): When installing
>   from a local checkout, store the value of `:lisp-dir' property of
>   `pkg-spec' in a "Package-spec" header in a generated autoloads
>   indirection file.
> * lisp/emacs-lisp/package-vc.el (package-vc--pkg-spec-from-autoloads):
>   New function to retrieve package spec from a "Package-spec" header
>   from autoloads indirection file (if any).
> * lisp/emacs-lisp/package-vc.el (package-vc-rebuild): Retrieve package
>   spec from autoloads indirection file (if any) and use it while calling
>   `package-vc--unpack-1'.
> * lisp/emacs-lisp/package-vc.el (package-vc-upgrade): Retrieve package
>   spec from autoloads indirection file (if any) and use it while calling
>   `package-vc--unpack-1' and for `vc-pull'.
>
> fixes: bug#79188

(The formatting is off here as well, but again, I can take care of that.
In case you did not know, in log-edit-mode, you can use the
`log-edit-generate-changelog-from-diff' command (bound to C-c C-w) to
generate a changelog from the current diff).

> ---
>  lisp/emacs-lisp/package-vc.el | 46 +++++++++++++++++++++++++++++------
>  1 file changed, 39 insertions(+), 7 deletions(-)
>
> diff --git a/lisp/emacs-lisp/package-vc.el b/lisp/emacs-lisp/package-vc.el
> index 9e118c7af02..400e648b8f5 100644
> --- a/lisp/emacs-lisp/package-vc.el
> +++ b/lisp/emacs-lisp/package-vc.el
> @@ -508,7 +508,14 @@ package-vc--unpack-1
>          (when lisp-dir
>            (write-region
>             (with-temp-buffer
> -             (insert ";; Autoload indirection for package-vc\n\n")
> +             (insert ";; Autoload indirection for package-vc\n")
> +             (insert ";; Package-spec: ")
> +             ;; Store the pkg-spec such that it can be reused by
> +             ;; `package-rebuild' and `package-vc-upgrade' to restore
> +             ;; the same conditions as were when the indirection has
> +             ;; been created for the first time.
> +             (prin1 pkg-spec (current-buffer))

This is strictly speaking not robust, as doesn't assure us that
something like (prin1 "one\ntwo") will result in a string without
newlines and not "break out" of the comment.  If anything, we should
consider storing this in a separate file, but more on that below.

> +             (insert "\n\n")
>               (prin1 `(load (expand-file-name
>                              ,(expand-file-name auto-name lisp-dir)
>                              (or (and load-file-name
> @@ -589,6 +596,19 @@ package-vc--unpack-1
>  
>  (declare-function project-remember-projects-under "project" (dir &optional recursive))
>  
> +(defun package-vc--pkg-spec-from-autoloads (pkg-desc)
> +  "Read a \"Packcage-spec\" header from autoloads file for PKG-DESC."
> +  (when-let* ((name (package-desc-name pkg-desc))
> +              (autoloads (expand-file-name (format "%s-autoloads.el" name)
> +                                           (package-desc-dir pkg-desc)))
> +              ((file-exists-p autoloads))
> +              (spec (with-temp-buffer
> +                      (insert-file-contents autoloads)
> +                      (ignore-errors
> +                        (read (lm-header "package-spec"))))))
> +    (cons (symbol-name name)
> +          spec)))

Generally speaking I am not sure if this approach is necessary, as we
already have `package-vc--desc->spec' and introducing this hack would
introduce an ambiguity as to where the authoritative package
specification is stored.

> +
>  (defun package-vc--clone (pkg-desc pkg-spec dir rev)
>    "Clone the package PKG-DESC whose spec is PKG-SPEC into the directory DIR.
>  REV specifies a specific revision to checkout.  This overrides the `:branch'
> @@ -756,7 +776,10 @@ package-vc-upgrade
>    ;;
>    ;; If there is a better way to do this, it should be done.
>    (cl-assert (package-vc-p pkg-desc))
> -  (letrec ((pkg-dir (package-desc-dir pkg-desc))
> +  (letrec ((pkg-spec (package-vc--pkg-spec-from-autoloads pkg-desc))

So we are just shadowing the pkg-spec passed as an argument?

> +           (pkg-dir (package-desc-dir pkg-desc))
> +           (source-dir (or (plist-get (cdr pkg-spec) :lisp-dir)
> +                           pkg-dir))

Just an an example of what I was talking about above: Here for instance
we already have an inconstancy.  Everywhere else in the file, we assume
that a package specification is just a plist, and not a (PACKAGE-NAME
. SPEC-PLIST) that requires a `cdr'. to access.

>             (vc-flags)
>             (vc-filter-command-function
>              (lambda (command file-or-list flags)
> @@ -764,18 +787,22 @@ package-vc-upgrade
>                (list command file-or-list flags)))
>             (post-upgrade
>              (lambda (_command _file-or-list flags)
> -              (when (and (file-equal-p pkg-dir default-directory)
> +              (when (and (file-equal-p source-dir default-directory)
>                           (eq flags vc-flags))
>                  (unwind-protect
>                      (with-demoted-errors "Failed to activate: %S"
> -                      (package-vc--unpack-1 pkg-desc pkg-dir))
> +                      (let ((package-vc-selected-packages
> +                             (if pkg-spec
> +                                 (cons pkg-spec package-vc-selected-packages)
> +                               package-vc-selected-packages)))
> +                        (package-vc--unpack-1 pkg-desc pkg-dir)))

You'll have yo remind me (i.e. add a comment) why you are binding the
variable here and why you are distinguishing between pkg-spec being nil
or not?

>                    (remove-hook 'vc-post-command-functions post-upgrade))))))
>      (add-hook 'vc-post-command-functions post-upgrade)
>      (with-demoted-errors "Failed to fetch: %S"
>        (require 'vc-dir)
>        (with-current-buffer (vc-dir-prepare-status-buffer
> -                            (format " *package-vc-dir: %s*" pkg-dir)
> -                            pkg-dir (vc-responsible-backend pkg-dir))
> +                            (format " *package-vc-dir: %s*" source-dir)
> +                            source-dir (vc-responsible-backend source-dir))
>          (vc-pull)))))
>  
>  (defun package-vc--archives-initialize ()
> @@ -966,7 +993,12 @@ package-vc-rebuild
>  is the responsibility of `package-vc-upgrade'.  Interactively,
>  prompt for the name of the package to rebuild."
>    (interactive (list (package-vc--read-package-desc "Rebuild package: " t)))
> -  (package-vc--unpack-1 pkg-desc (package-desc-dir pkg-desc)))
> +  (let* ((pkg-spec (package-vc--pkg-spec-from-autoloads pkg-desc))
> +         (package-vc-selected-packages
> +          (if pkg-spec
> +              (cons pkg-spec package-vc-selected-packages)
> +            package-vc-selected-packages)))
> +    (package-vc--unpack-1 pkg-desc (package-desc-dir pkg-desc))))
>  
>  ;;;###autoload
>  (defun package-vc-prepare-patch (pkg-desc subject revisions)

Previous Next

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