From unknown Fri Aug 15 04:04:48 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#79188 <79188@debbugs.gnu.org> To: bug#79188 <79188@debbugs.gnu.org> Subject: Status: 31.0.50; Cannot build packages installed from VC Reply-To: bug#79188 <79188@debbugs.gnu.org> Date: Fri, 15 Aug 2025 11:04:48 +0000 retitle 79188 31.0.50; Cannot build packages installed from VC reassign 79188 emacs submitter 79188 Przemyslaw Kryger severity 79188 normal tag 79188 patch thanks From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 07 07:34:05 2025 Received: (at submit) by debbugs.gnu.org; 7 Aug 2025 11:34:05 +0000 Received: from localhost ([127.0.0.1]:33849 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ujysm-0002EI-Sb for submit@debbugs.gnu.org; Thu, 07 Aug 2025 07:34:05 -0400 Received: from lists.gnu.org ([2001:470:142::17]:42316) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ujysk-0002Dc-S7 for submit@debbugs.gnu.org; Thu, 07 Aug 2025 07:34:03 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ujysa-0007WK-Mi for bug-gnu-emacs@gnu.org; Thu, 07 Aug 2025 07:33:55 -0400 Received: from mail-wm1-x32f.google.com ([2a00:1450:4864:20::32f]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ujysW-0007qp-Mu for bug-gnu-emacs@gnu.org; Thu, 07 Aug 2025 07:33:51 -0400 Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-459d62184c9so5663865e9.1 for ; Thu, 07 Aug 2025 04:33:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1754566426; x=1755171226; darn=gnu.org; h=mime-version:message-id:date:subject:to:from:from:to:cc:subject :date:message-id:reply-to; bh=SL9tP2R0BjZ7TeEKpinYo5S9siboij0lwOHCGWJG7g0=; b=OTCCsCILlwqE8y18losbzhBWyFisFYVPc9BSnbeQyfWhT4ztz1X5vFdFNYnrOaK2UR A32lQs8pY6oL4RzNkJ3Q3aQJ6kLNNU37biKkUwaBzh5uLiQfagcSJ4wMqQRcXKV7TKiS EA9WL5oRfvjfF1rSyUGDpoeIXmwq3ENkY6MYRxLFbqkNLGGhMyUCeBPB9OtugKfHALwN lEaTrzlVzbCRvqFyxSR/HB2ayq4sBBYffgHYas6QlItJ5CihUDvhO6vuBndIiw6mjc7c Gxvl+tNSWgnZ1k0DAcpkOcdBQ47LYIXj6dLvHpGjTpLgMvqjGA8jXu+nVHEqp4es5l/u ImqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754566426; x=1755171226; h=mime-version:message-id:date:subject:to:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=SL9tP2R0BjZ7TeEKpinYo5S9siboij0lwOHCGWJG7g0=; b=FdA4FTtRupia3Gx0MISp/FecO2rjLAV3NhnZNKYgnT5K3vnMO/vtCr4sMuHXHhgWb1 4c3DCgnHwtcBeSZmxE8l2hLheGh65im3uLztmQ2Cm2cVsIVhzCfRi3TLmL1QhI+qSSwT /KghCM/6E+IipKK4HR0Z8caeEXyWEXhrePprS0J/R3U4mkUCtbC1r8695OfyrUonGSlo y89+qxjoE4QI77lytTPNl4RI5C1aeuKaeISN8pQIYYWnLOJKxaHL+9cDKc87gkCntcuW GQ3CDZjnx22XGDHOL7GOzkHT4Tb/bXfHJmClHaLaeM7J+1k7GVLV2y07JHuaVEDJkqq9 iynQ== X-Gm-Message-State: AOJu0YwkuvagC4+/QvCgGQ2XtpBCv4bonE9FOlbIBcMuCaMhvLVP0bzU a5YBp/wHHAy8kHfAD8sUmNTcRRv4cXp0WcJDo3ohJx3isRFEyF+fCfnPPbpkiQ== X-Gm-Gg: ASbGncthvgjMOtktH1e/yu0iu6INXDUE2j4t222a05M64XBR24AZ5I52AeX9qBAaKfc Kx8npQH5LA+GYMpsm7X50ZwG8yfIg+UoItxrdlso6wxW8q4kzMKSKnFu0dBgWTgcSYcM4NrxLyF tGyjkr+BxDwYzeI6/zaUIllDC8r/3rDOt1RfwEX+MwiJVqOMLJQzbi43kjJYSnJDu+m+liq3F8X pum5JNDwGmQGTY8HeRPkyA9Iuk5zrtFwWuvBcevky13uh4ZdoqrwERad/t9G6SUiY4afv1hbWG/ JdNox/+J3WZf1EbjGOGL5XL5quysBEUsv13X85b3cOvR8Grrd9bXOuqHha0CXxx3MekHTPs1SDn 4YnkvmF5WiPfDWAozt4rHFdXtmsXLcz3J/sF/u+xwnEv/2/OQUK1qn0JIY+yhgGw= X-Google-Smtp-Source: AGHT+IGOBUIT3i5F07Z0HqRXP4m7g3PdTVBMi6XEUf6qeOOId3X7ndTsbcKtfYuTkqB6TqLntW8/KQ== X-Received: by 2002:a05:600c:4ece:b0:458:a559:a693 with SMTP id 5b1f17b1804b1-459e70d9e6cmr63833075e9.18.1754566425914; Thu, 07 Aug 2025 04:33:45 -0700 (PDT) Received: from Przemyslaws-MacBook-Air.local ([2a00:23c8:b1c:3801:1c7a:76b8:c20f:aea9]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-459e0e70218sm118594055e9.20.2025.08.07.04.33.45 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Aug 2025 04:33:45 -0700 (PDT) From: Przemyslaw Kryger To: bug-gnu-emacs@gnu.org Subject: 31.0.50; Cannot build packages installed from VC X-Debbugs-Cc: Philip Kaludercic Date: Thu, 07 Aug 2025 12:33:44 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2a00:1450:4864:20::32f; envelope-from=pkryger@gmail.com; helo=mail-wm1-x32f.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) 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)) From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 07 08:55:55 2025 Received: (at 79188) by debbugs.gnu.org; 7 Aug 2025 12:55:55 +0000 Received: from localhost ([127.0.0.1]:34010 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uk09y-0006Cs-3z for submit@debbugs.gnu.org; Thu, 07 Aug 2025 08:55:55 -0400 Received: from mout01.posteo.de ([185.67.36.65]:55601) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uk09v-0006CX-2D for 79188@debbugs.gnu.org; Thu, 07 Aug 2025 08:55:52 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 77CFD240027 for <79188@debbugs.gnu.org>; Thu, 7 Aug 2025 14:55:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posteo.net; s=1984.ea087b; t=1754571344; bh=Bz/AmoCwUG2eK15/vp/qodAT60wY6JhiY9im7rGh9fQ=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=infYiHWx1tCpQngh7Zke+BmO4U9zXtPYIyvckVv+PpFeJilQRHcvnS5hsRegz/Csu s77uhtohW3bRTcZoSIWmCOhfnqD5dVOqqC3pz0KKRKbmwwwSzXzwHysPQETutYzESI hREoXEas2/LF5lv52LZmKlW3fHr0f7cb0+ZpR0V1oD16UqZwlIrxEznwbo53WfuXq/ KUMqeSAD1QqJXpMVjVBnWT2z8R2U8y+9htftFkxEZVa76Yyrq+hRrNMZtJZp+G3JH5 fVlAyHdX7/SNEG2x7zu0CwMK4e6bHwmWdMWc5n7KgDLSO25suhHp8NViy9cDm8UaN7 uC+UaFcfCFVtHi3KMshlN+trYEYgzl2N5yj9Zi3YaHFHqs0QTP/3jERcq3jFxBM3PE r7GvQQ8O5fCbSvU8iS0h1mmc6bzcXQcEe8CC15GbJbg3z+gty75ow+QhtpqtFe5Z4T aIbyq7D4EvJt9WfgvplRbHPGnNESYGnYpcVCsckVJUFf4uPH9yd Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4byRwb4hLrz9rxK; Thu, 7 Aug 2025 14:55:43 +0200 (CEST) From: Philip Kaludercic To: Przemyslaw Kryger Subject: Re: bug#79188: 31.0.50; Cannot build packages installed from VC In-Reply-To: References: Date: Thu, 07 Aug 2025 12:55:43 +0000 Message-ID: <87jz3f2svk.fsf@posteo.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79188 Cc: 79188@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) --=-=-= Content-Type: text/plain Przemyslaw Kryger 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: --=-=-= Content-Type: text/x-patch Content-Disposition: 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 --=-=-= Content-Type: text/plain > > 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 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 07 12:53:21 2025 Received: (at 79188) by debbugs.gnu.org; 7 Aug 2025 16:53:21 +0000 Received: from localhost ([127.0.0.1]:35718 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uk3rk-0001SJ-R0 for submit@debbugs.gnu.org; Thu, 07 Aug 2025 12:53:21 -0400 Received: from mail-pj1-x1036.google.com ([2607:f8b0:4864:20::1036]:55663) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uk3rh-0001Rz-Ft for 79188@debbugs.gnu.org; Thu, 07 Aug 2025 12:53:18 -0400 Received: by mail-pj1-x1036.google.com with SMTP id 98e67ed59e1d1-3214762071bso1522523a91.3 for <79188@debbugs.gnu.org>; Thu, 07 Aug 2025 09:53:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1754585591; x=1755190391; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=4C6CwUQ8WPrNCJE1oMOd+L11AcyE8reQkwVcHGaKb8I=; b=h67uALqfZ5YekZ+iU56sCWWEG77BufommcGPmLMIz0XsFnTpt3cNC8aalVnkZ/USdW yCKHBeZW7WkGXTvs5bQWGUzbYb6z3EqyV0z9sjWoS3sztf6zG96EgMOIDlPPCd5v4kf7 rasF027djjpTAyIr+zi0WLgz9fcwUIUr+zOsWhK6q2PlMnTQgzQesJ8hhXO0cwl2zd9O ccn9tt+wC5J+uccjO0l+Vx+c5lbkaZYVYxYilwfqY25tIrHGn8Q1lR02Ba0um6KaexlG m7Y/W0q1johpV2rTDoFd5QY32bcFkcNhV6ZLao5PoYvptpdvWiJWWY+wsmCahMdxx/RW q6kQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754585591; x=1755190391; h=content-transfer-encoding:cc:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=4C6CwUQ8WPrNCJE1oMOd+L11AcyE8reQkwVcHGaKb8I=; b=Xz1xQBQ8loWHY5okQwqJj1zBHY9hdtF0uQEjT/F4PqaVJ4zkLWidEn+3t2+X+MpNC0 e5JmXaMbzE88XuWyJJ1JYXh+NhPakpn0ClwUiasScknsy8iKRAm40UYUMuXhcHP5VvB7 69TrHbqTnXp1E+79eIZsRm8LDEpJMjBddqulH2z9rgOEGniA512u1CiH02XDvjcw+eAx 21skxsJDRHVKbz05DqiLKKS5nkGNWqJ+aSJ0bJjTcwP+Bq2AbUyJbNkam0d6E2fX82o1 8spwzrEwXE0sDua5HWmqskC9zqGwdQ82aDLdA6Ca6bQDQuZwR6VWZt9VBCRUhE/VoXby RIOQ== X-Gm-Message-State: AOJu0YyIy30DX8Y9JJb0xPRmkvwY9cxEKJIO4/xf8XnT7XHDh848exXT peTBldZNga0YYUs9IPRxfcN1gkhvacAQc4eosQao1pryDCY5QOYEl4cxAhZI15RN5sSNUUmARFM D3aYgn+zQb0w6XPPAYmg1pM1gaZKs3GEo9g== X-Gm-Gg: ASbGncvJvk8FADQzjpMiqrGdalOGdvSDcMAxJl4apUV3VYHpqjAZdSWedAQ084T7XfL KP9HIwmWFyvt+oNuIxGofZAQ/aNZKMXrZE1oOYTLnUZQ19snYwlaIpAaEtOT3eK/EutYywXO3hB wU6kDeJe9vnk/c31oGgB86bSPrL3YFPIOtZIunz1hy481e4YMk5MhlmiJIt9ks+ROOdKUMzMI+y yy9+S6W01s974Cd8c4vj41ZkX3DP+aut52RcRQRX740O/3HAuA= X-Google-Smtp-Source: AGHT+IE3ZzNnk/ikvriWlm9i2gA9Un0YQ35IXyUkVUV6bXF77Vf+D5ADt7LDhvseAi0CTfvWDSeXlI0esatLn3bwJGQ= X-Received: by 2002:a17:90b:3c4b:b0:31e:ff94:3fa0 with SMTP id 98e67ed59e1d1-32166c10291mr9505743a91.6.1754585590965; Thu, 07 Aug 2025 09:53:10 -0700 (PDT) MIME-Version: 1.0 References: <87jz3f2svk.fsf@posteo.net> In-Reply-To: From: =?UTF-8?Q?Przemys=C5=82aw_Kryger?= Date: Thu, 7 Aug 2025 17:53:00 +0100 X-Gm-Features: Ac12FXykuCtVBaEfHQF2gbNoLSxWChl1jE_gmkr01oNSOi5YpMM5NP-bwJXwj5M Message-ID: Subject: Fwd: bug#79188: 31.0.50; Cannot build packages installed from VC Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 3.4 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Forwarding - missed the debbugs Forwarded message --------- From: Przemysław Kryger Date: Thu, 7 Aug 2025 at 17:46 Subject: Re: bug#79188: 31.0.50; Cannot build packages installed from V [...] Content analysis details: (3.4 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.0 SPF_PASS SPF: sender matches SPF record 1.2 MISSING_HEADERS Missing To: header 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (pkryger[at]gmail.com) -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [2607:f8b0:4864:20:0:0:0:1036 listed in] [list.dnswl.org] 2.2 MALFORMED_FREEMAIL Bad headers on message from free email service X-Debbugs-Envelope-To: 79188 Cc: 79188@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 2.4 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Forwarding - missed the debbugs Forwarded message --------- From: Przemysław Kryger Date: Thu, 7 Aug 2025 at 17:46 Subject: Re: bug#79188: 31.0.50; Cannot build packages installed from V [...] Content analysis details: (2.4 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [2607:f8b0:4864:20:0:0:0:1036 listed in] [list.dnswl.org] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.0 SPF_PASS SPF: sender matches SPF record 1.2 MISSING_HEADERS Missing To: header 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (pkryger[at]gmail.com) 2.2 MALFORMED_FREEMAIL Bad headers on message from free email service -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager Forwarding - missed the debbugs ---------- Forwarded message --------- From: Przemys=C5=82aw Kryger Date: Thu, 7 Aug 2025 at 17:46 Subject: Re: bug#79188: 31.0.50; Cannot build packages installed from VC To: Philip Kaludercic Philip Kaludercic writes: > Przemyslaw Kryger 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 pac= kage 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-projectil= e") 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 n= il >> :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 . "2e= cd3d85b7077f39bb2fefe2227cc46931d4b92b")) :signed nil)) >> funcall-interactively(package-vc-rebuild #s(package-desc :name helm-pr= ojectile :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, 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. 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=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. 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. From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 08 07:07:32 2025 Received: (at 79188) by debbugs.gnu.org; 8 Aug 2025 11:07:32 +0000 Received: from localhost ([127.0.0.1]:37414 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ukKwd-0004cS-8S for submit@debbugs.gnu.org; Fri, 08 Aug 2025 07:07:32 -0400 Received: from mail-wm1-x331.google.com ([2a00:1450:4864:20::331]:44089) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1ukKwX-0004c4-L0; Fri, 08 Aug 2025 07:07:29 -0400 Received: by mail-wm1-x331.google.com with SMTP id 5b1f17b1804b1-459ebb6bbdfso13197535e9.0; Fri, 08 Aug 2025 04:07:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1754651239; x=1755256039; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:cc:references:in-reply-to :subject:to:from:from:to:cc:subject:date:message-id:reply-to; bh=ZQOFB19jutiNe16VqKa4qnB5yIBLOl7aFrsZcPVe+J8=; b=DvT6mZ3j0sBtEtm3LppUwCe3AoT3R1SLJ3XmYkhCGakLJKs3LB1r0hcQEtYKj1g7aC G0rUGiG8FS2C5QzhgIXlhY7ztASZX9444PVjoeF9413/O6tWh5iUDN4tp4PPPoN2p1fA EFLWQI82WJUFXtys35p7RsjXwATWnuZGkK35oYmARGUjddKNK1kE3W9tUC0NzQFu/tum Ai3L+4VPSCQGuOwHG2qwNRrXGS4g9ZubDAcyCeV4zDjE04pkgbUYPpgDs9tvTGaMIB0u GOGPAdn1Uw+pt6R/uyqnf/z7kQVTkqNIOt1gsDmIGL70IQ6G5k3VKzQGR3KFx6DQxhVj S26A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754651239; x=1755256039; h=mime-version:user-agent:message-id:date:cc:references:in-reply-to :subject:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ZQOFB19jutiNe16VqKa4qnB5yIBLOl7aFrsZcPVe+J8=; b=YXWrIFGQ1GThwGUMXFUfvpfjVdk7f2y16JpZTviKjdasjcem0E7kLFCRTs6D45PGFB VX+MpLPM1P/YdG7Ilt0jveZWeQLNBFiMXweSyRpY68Xif/1OBR191dTwdSg2g9yDRIX9 LsxQnuJLVY2rJIwMWQRJbDAo6udayfisEOIQZRn6l/4WrID8sKKyqVzeNZYGxCcgSF70 0jwH3L4EW8VbuQf5lUqsNCwiBPmAE8EvTzwe7oi+Abt28StX1Nak1iEOfjF8SB9zfHh/ LTOAC80gi8wzz46FnYWWvNIv87MyMUeTAIR/az7weaE+22+N6M5DSOXnOaKIwjM3HqHy 85qg== X-Forwarded-Encrypted: i=1; AJvYcCWvfN+CVlYu44WdAtA1XaxPv5v4AiMnzy5BDQRZfMJiCAEO75201PFBUGGAy409IbaXenhprZn/@debbugs.gnu.org X-Gm-Message-State: AOJu0YxjGLWzpsK2bK7vs1bEw1UPuWXq2NBcZS19XZneZinP3IKR4O/K /Dpk2x2Zpm8uxyde5Ts6VL4U5qLFX+79CCpzUYbl3PuY2Q0m3JLt2OLeLtCvliBi X-Gm-Gg: ASbGnctdaxBR99FjGBrYULs1UdCxSENkEU42yz3TSFgDENFMnpCm4q2f1C+wMgMzVa2 HcV51KTwH66lCd+Zx/CTHgDcElvrvkqKHiIES3YezjFG+e6CC1XGbr6/q034VH7BKPk9xNoX4Xo UNCnh6XWQ1jjplo6m2rBVZK7FTCeLcl635IOIrK1pveQ6ArRHvErvBiGpqtVumYt6sETZQazq6k j7LPTZfDwdUY1OVIm894O3Ioe49qmZNeRu8O/lo9Dtv48MVkX8meFOUEOQVl8DEmQ0G94XmxVw2 mhp2WeM13wVPtoAfDMFbAfBSzKYKO1nymTjLgXbmG7ET6OcaSd9a1x92XoLfk2V/tpmbU6eFNSR D/pQaYLCiMlduFWA9L38KwRYPae+Qq1rp3iHa3y3rxkvddIWGm1RlVqkQLhzYYEI= X-Google-Smtp-Source: AGHT+IEJfEWQyHvFMRGKyKCLfbUiEmHpRzVQDMJQn9nc3HGSpNUl7OGFC2Rr8R0wK2DgMCg+7CcCsg== X-Received: by 2002:a05:600c:15ca:b0:459:dde3:1a55 with SMTP id 5b1f17b1804b1-459f5507f88mr13471325e9.24.1754651238532; Fri, 08 Aug 2025 04:07:18 -0700 (PDT) Received: from Przemyslaws-MacBook-Air.local ([2a00:23c8:b1c:3801:b8d6:64db:4c9b:7a99]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-459e5862fd9sm141886855e9.16.2025.08.08.04.07.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Aug 2025 04:07:17 -0700 (PDT) From: =?utf-8?Q?Przemys=C5=82aw_Kryger?= To: Philip Kaludercic Subject: Re: bug#79188: 31.0.50; Cannot build packages installed from VC In-Reply-To: (=?utf-8?Q?=22Przemys=C5=82aw?= Kryger"'s message of "Thu, 7 Aug 2025 17:53:00 +0100") References: <87jz3f2svk.fsf@posteo.net> Date: Fri, 08 Aug 2025 12:07:14 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79188 Cc: 79188@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable tags 79188 + patch quit Przemys=C5=82aw Kryger 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=3D79188#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, s= t=3D > ep. >> ;; E.g. for multi-package installs, we should first install all= =3D > 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=3DC3=3DAFve - 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? --=-=-= Content-Type: text/plain Content-Disposition: attachment; filename=0001-Compile-file-in-local-checkout-directory.patch Content-Description: patch >From 56fa1014b1f8f2eb7f6d87304c3f31604fed48ba Mon Sep 17 00:00:00 2001 From: Philip Kaludercic Date: Fri, 8 Aug 2025 11:43:24 +0100 Subject: [PATCH 1/2] Compile file in local checkout directory This partially fixes bug#79188. * 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 --=-=-= Content-Type: text/plain Content-Disposition: attachment; filename=0002-Store-local-checkout-directory-in-autoloads-indirect.patch Content-Description: patch >From 07596327df8bee5831003b62c811dd3fc53f2a88 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Przemys=C5=82aw=20Kryger?= 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 --- 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)) + (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))) + (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)) + (pkg-dir (package-desc-dir pkg-desc)) + (source-dir (or (plist-get (cdr pkg-spec) :lisp-dir) + pkg-dir)) (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))) (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) -- 2.50.1 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 09 07:44:12 2025 Received: (at 79188) by debbugs.gnu.org; 9 Aug 2025 11:44:12 +0000 Received: from localhost ([127.0.0.1]:40478 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ukhze-0005xD-PJ for submit@debbugs.gnu.org; Sat, 09 Aug 2025 07:44:11 -0400 Received: from mout02.posteo.de ([185.67.36.66]:46923) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ukhza-0005wV-O9 for 79188@debbugs.gnu.org; Sat, 09 Aug 2025 07:44:08 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 43227240101 for <79188@debbugs.gnu.org>; Sat, 9 Aug 2025 13:44:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posteo.net; s=1984.ea087b; t=1754739840; bh=VjARZ1beZChajdksJ7b3XVERxTH935ERrdzUQsKzY+s=; h=From:To:Cc:Subject:Autocrypt:OpenPGP:Date:Message-ID:MIME-Version: Content-Type:Content-Transfer-Encoding:From; b=j/dTldmJ9sWlr0ND49/APn1/gIKeX0ZXh8fjavbBDdD+8XWzrmGFX/kJBfTXsz9pd hPwaI6eDvHwlPlcZcdXV/Vyu0Kw09GJi74i5InzP9bdhB4P/GkU3XFLEXAi4LX1ZjF hyb0Dcps147bZQk+JMVScLrEO4Qfl4mwG8GzobIukE6wzlJ44iXpPojQGa0mPs5dJ0 okk68EDWx/6p+WLeYHxKfErwfLDmwULIf0sACCm/3dmuZ08BtOP/ItY5+7djXqk7Cx +3R11QCdGmZUY+TfXpYiz30AAFwG12RgmtAW9VehkMkZQPRAKomnK8HavC57JatIHH q/wC+q9M+CpX8rHaQG2QkW2tp+4QlS0Kd4TEH5gZ04UPX3CgKI2soI15gjZ6IAYblu BbAMYre061PDKy3TTnGmoYyqJc1Q9Zm+Ha3lYL07r/NEF9Pdbn0UsGoVUH++i4UjLu K/3jRX44IKXCp0Azzy3FJK1Ek/VkDElr8zG1tw55V1uN6s1XBNd Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4bzfDv4jJRz9rxW; Sat, 9 Aug 2025 13:43:59 +0200 (CEST) From: Philip Kaludercic To: =?utf-8?Q?Przemys=C5=82aw?= Kryger Subject: Re: bug#79188: 31.0.50; Cannot build packages installed from VC In-Reply-To: References: <87jz3f2svk.fsf@posteo.net> Autocrypt: addr=philipk@posteo.net; keydata= mDMEZBBQQhYJKwYBBAHaRw8BAQdAHJuofBrfqFh12uQu0Yi7mrl525F28eTmwUDflFNmdui0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiWBBMWCAA+FiEEDg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwMFCQHhM4AFCwkI BwIGFQoJCAsCBBYCAwECHgECF4AACgkQ8xYDWXahwulikAEA77hloUiSrXgFkUVJhlKBpLCHUjA0 mWZ9j9w5d08+jVwBAK6c4iGP7j+/PhbkxaEKa4V3MzIl7zJkcNNjHCXmvFcEuDgEZBBQQhIKKwYB BAGXVQEFAQEHQI5NLiLRjZy3OfSt1dhCmFyn+fN/QKELUYQetiaoe+MMAwEIB4h+BBgWCAAmFiEE Dg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwwFCQHhM4AACgkQ8xYDWXahwukm+wEA8cml4JpK NeAu65rg+auKrPOP6TP/4YWRCTIvuYDm0joBALw98AMz7/qMHvSCeU/hw9PL6u6R2EScxtpKnWof z4oM OpenPGP: id=7126E1DE2F0CE35C770BED01F2C3CC513DB89F66; url="https://keys.openpgp.org/vks/v1/by-fingerprint/7126E1DE2F0CE35C770BED01F2C3CC513DB89F66"; preference=signencrypt Date: Sat, 09 Aug 2025 11:43:59 +0000 Message-ID: <87h5ygyb28.fsf@posteo.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79188 Cc: 79188@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Przemys=C5=82aw Kryger writes: > tags 79188 + patch > quit > > Przemys=C5=82aw Kryger 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 invol= ve >>> 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=3D79188#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=3D >> ep. >>> ;; E.g. for multi-package installs, we should first install al= l =3D >> 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=3DC3=3DAFve - 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 > 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, 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 > --=20 > 2.50.1 > > > From 07596327df8bee5831003b62c811dd3fc53f2a88 Mon Sep 17 00:00:00 2001 > From: =3D?UTF-8?q?Przemys=3DC5=3D82aw=3D20Kryger?=3D > Date: Fri, 8 Aug 2025 11:43:52 +0100 > Subject: [PATCH 2/2] Store local checkout directory in autoloads indirect= ion > > * 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 >=20=20 > (declare-function project-remember-projects-under "project" (dir &option= al recursive)) >=20=20 > +(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" nam= e) > + (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 `:bra= nch' > @@ -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-pack= ages) > + 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-di= r)) > (vc-pull))))) >=20=20 > (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)))) >=20=20 > ;;;###autoload > (defun package-vc-prepare-patch (pkg-desc subject revisions) From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 11 06:29:20 2025 Received: (at 79188) by debbugs.gnu.org; 11 Aug 2025 10:29:21 +0000 Received: from localhost ([127.0.0.1]:47188 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ulPmJ-0003bP-Ia for submit@debbugs.gnu.org; Mon, 11 Aug 2025 06:29:20 -0400 Received: from mail-wm1-x333.google.com ([2a00:1450:4864:20::333]:52441) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1ulPmE-0003b7-VX for 79188@debbugs.gnu.org; Mon, 11 Aug 2025 06:29:16 -0400 Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-459ddf8acf1so35032955e9.0 for <79188@debbugs.gnu.org>; Mon, 11 Aug 2025 03:29:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1754908148; x=1755512948; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=OLhtoATN/xu1zedwHitBZfjxOnKzzZxZIdGEiyPSHDM=; b=G0NPdwIEJ6p+ILXXTeIQF1RvZKfeHPA4INhIC9NNf9mcGeIP1C/EeN6enzimfhT8V0 LywMR0+htfb1AQ33heirPAwSlSJ3A+KAjgfuHhN0nCRyaAypPD77zk/I7zieNDKyeWkB 3hf7DfUgAVJzKDWokInOgilr5EXNEagXoFADFbFUjMjm8mmgnc4YumMVLESNneSBdGKs 8ii62eiUuoyxvgjTfmLnGUltfb9ROyI5hdD8d6IBwqdF+PqgEnGzcjo1D9xmSrMFwoxE gKQcsD+WdGcNp5pcrXcoj7wpBQ1WYqyMT6tj1buouiQKCji+hBUvAIh2UHOTVIwvpcnW IhLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754908148; x=1755512948; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=OLhtoATN/xu1zedwHitBZfjxOnKzzZxZIdGEiyPSHDM=; b=f3OaaOMHtIlk7fv9gxrk+0esJ4VTo/n01RkhE0/mlNPgSlr72VkEYwqWCCJIFjrdx5 tNvHIAFpyu76H0cQUYQ6MWYqV2JAWDS3R0DAx/T37Hug1OC82WxR2nrRUn+yVftUxdpP DntDOBpiN0AcwANS3Q805BZIop5xKDfY18oyI/cS1oUG93rN4hZ9lgb5UBx37/FiCYkv HqgJ/LfHvSDwcBZgo5GE+mL4HvnR2WyopspsVxxF7yzLyzRF5+glgn0WFgAPgm0Qy4Ib 7YnxqvVVpsSs5C1y43ry8wxkZdsXppjtTb0tmsnK3gs5mXpyTpHzsZDolS8rZtWNlUHa Zyeg== X-Gm-Message-State: AOJu0Ywh0RGra010+2roDF7inMCIHFnqbZ3MGpyvh0YVwzDyopugoo3g rRKoi9Jdh6mIb+ltbF8UA40/RxmXnygpl0EYOU2gYJYRH89wjQ8nZBp1nO1E7A== X-Gm-Gg: ASbGncubh63+EdFZFNYzAwP/utI/9KdObLglHaGtHQHoAmJSoGqyNl1eyz1Hkl01QuO H4XWlayBrPz9mE9wfy3T5Z04+MpLyuocE9C5itidQa1o7MXlcNIAXRPdY4MtSce0BukstON8+fB SZ5Q7/cDd6/fb5+3wGPfh7CvIXBRrAeLXzuItTwlkzxOr1/dK3js+sb/pRjJ46RTK8bNUou9xNs 22z6B/+j/aeHu1xPeGB+N6jMz3b96TVyagfTD3nJQ2RU5iFO+6uBeCz/GYsrmIcHl7xs4/ll3re eEj6E0FEGpDfWgik2Umh5nsXHqldXRZMhMtedeaO77IwYyWwSDazdxoWMVEmZvIL3LW0/SwKtMB zBQBJTsdcL9brPKRc4KdeGMaq3Wh7faDmdkbiQ6ImYFIDaJO6KtTUVyt9bg18FKGKxRTURZmrVw == X-Google-Smtp-Source: AGHT+IGtyI9ANu0hiE9KmdINeHZx9LQyzkGRw+SfBDe36qsNeHzCmeCnu0K5Z26uyiofUwN2iNzYSw== X-Received: by 2002:a05:600c:4f42:b0:450:d01f:de6f with SMTP id 5b1f17b1804b1-459f4ec6a99mr119063975e9.15.1754908147302; Mon, 11 Aug 2025 03:29:07 -0700 (PDT) Received: from Przemyslaws-MacBook-Air.local ([2a00:23c8:b1c:3801:24a2:4c7c:7241:a5eb]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-458953eb7acsm488563545e9.28.2025.08.11.03.29.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Aug 2025 03:29:06 -0700 (PDT) From: =?utf-8?Q?Przemys=C5=82aw_Kryger?= To: Philip Kaludercic Subject: Re: bug#79188: 31.0.50; Cannot build packages installed from VC In-Reply-To: <87h5ygyb28.fsf@posteo.net> (Philip Kaludercic's message of "Sat, 09 Aug 2025 11:43:59 +0000") References: <87jz3f2svk.fsf@posteo.net> <87h5ygyb28.fsf@posteo.net> Date: Mon, 11 Aug 2025 11:29:03 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79188 Cc: 79188@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain Philip Kaludercic writes: [...] >>> 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? Yes, I did meant that place. > 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? It does. Where do you recommend to post such a feature request be posted? debbugs? emacs-devel? >> From 56fa1014b1f8f2eb7f6d87304c3f31604fed48ba Mon Sep 17 00:00:00 2001 >> From: Philip Kaludercic >> 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. [...] >> From 07596327df8bee5831003b62c811dd3fc53f2a88 Mon Sep 17 00:00:00 2001 >> From: =?UTF-8?q?Przemys=C5=82aw=20Kryger?= >> 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). Thank you for pointing that out, and recommendation of `log-edit-mode'. Do you know if that can be achieved from within `magit' (or are there a known integration points)? I haven't posted too many patches to Emacs, so my format-fu may be not up to standard. I have attached new patches with comments addressed. I hope these are formatted better. If not please feel free to update. --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0001-Compile-file-in-local-checkout-directory.patch Content-Description: patch >From 8a785a9bb567e3143b5bd4ae58c3c355c7949945 Mon Sep 17 00:00:00 2001 From: Philip Kaludercic Date: Fri, 8 Aug 2025 11:43:24 +0100 Subject: [PATCH 1/2] Compile file in local checkout directory * 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'. (Bug#79188) --- 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 --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0002-Store-local-checkout-directory-in-autoloads-indirect.patch Content-Description: patch >From 24e845766d1a7c6f1d465db6c4041fc3a102d3a8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Przemys=C5=82aw=20Kryger?= Date: Fri, 8 Aug 2025 11:43:52 +0100 Subject: [PATCH 2/2] Store local checkout directory in autoloads indirection The checkout directory is saved in a generated autoloads indirection file when installing with `package-vc-install-from-checkout'. the intention to use the checkout directory in subsequent calls to `package-vc-update', `package-vc-upgrade', and `package-vc-ugrade-all'. * lisp/emacs-lisp/package-vc.el (package-vc--desc->spec): Retrieve package spec from package's autoloads indirection file when there's no spec in `package-vc-selected-packages'. (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. (package-vc-upgrade): When package has a local checkout - as defined by a presence of `:lisp-dir' property in `pkg-spec' - use it as a place where package source has been checked out. (Bug#79188) --- lisp/emacs-lisp/package-vc.el | 52 ++++++++++++++++++++++++----------- 1 file changed, 36 insertions(+), 16 deletions(-) diff --git a/lisp/emacs-lisp/package-vc.el b/lisp/emacs-lisp/package-vc.el index 9e118c7af02..87cfbc7595a 100644 --- a/lisp/emacs-lisp/package-vc.el +++ b/lisp/emacs-lisp/package-vc.el @@ -160,18 +160,28 @@ package-vc--desc->spec "Retrieve the package specification for PKG-DESC. The optional argument NAME can be used to override the default name for PKG-DESC." - (alist-get - (setq name (or name (package-desc-name pkg-desc))) - (if (and (package-desc-archive pkg-desc) - (not (alist-get name package-vc-selected-packages - nil nil #'string=))) - (alist-get (intern (package-desc-archive pkg-desc)) - package-vc--archive-spec-alists) - ;; Consult both our local list of package specifications, as well - ;; as the lists provided by the archives. - (apply #'append (cons package-vc-selected-packages - (mapcar #'cdr package-vc--archive-spec-alists)))) - '() nil #'string=)) + (let ((name (or name (package-desc-name pkg-desc)))) + (or + (alist-get + name + (if (and (package-desc-archive pkg-desc) + (not (alist-get name package-vc-selected-packages + nil nil #'string=))) + (alist-get (intern (package-desc-archive pkg-desc)) + package-vc--archive-spec-alists) + ;; Consult both our local list of package specifications, as well + ;; as the lists provided by the archives. + (apply #'append (cons package-vc-selected-packages + (mapcar #'cdr package-vc--archive-spec-alists)))) + '() nil #'string=) + (when-let* ((autoloads (expand-file-name (format "%s-autoloads.el" name) + (package-desc-dir pkg-desc))) + ((file-exists-p autoloads))) + (with-temp-buffer + (insert-file-contents autoloads) + (ignore-errors + (read (lm-header "package-spec")))))))) + (defun package-vc--read-archive-data (archive) "Update `package-vc--archive-spec-alists' for ARCHIVE. @@ -508,7 +518,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)) + (insert "\n\n") (prin1 `(load (expand-file-name ,(expand-file-name auto-name lisp-dir) (or (and load-file-name @@ -757,6 +774,9 @@ 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)) + (checkout-dir (or (plist-get (package-vc--desc->spec pkg-desc) + :lisp-dir) + pkg-dir)) (vc-flags) (vc-filter-command-function (lambda (command file-or-list flags) @@ -764,7 +784,7 @@ 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 checkout-dir default-directory) (eq flags vc-flags)) (unwind-protect (with-demoted-errors "Failed to activate: %S" @@ -774,8 +794,8 @@ package-vc-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*" checkout-dir) + checkout-dir (vc-responsible-backend checkout-dir)) (vc-pull))))) (defun package-vc--archives-initialize () -- 2.50.1 --=-=-= Content-Type: text/plain More comments below. I hope they will make easier to understand the new patches. >> --- >> 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. I agree with you. I have developed these patches trying to avoid touching any other workflow and leaned on the similar assumption/hack that has been implemented in `package-vc-install-from-checkout'. That is the variable `package-vc-selected-packages' will temporarily hold a stub spec that will allow `package-vc--unpack-1' to use the checkout directory and not the value of slot `:dir' in `pkg-desc'. The new patches attached to this message are implemented with a slightly different assumption: that `package-vc--unpack-1' will somehow get an appropriate `pkg-spec' for the package being installed. >> + (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. I am not really sure what did you mean by "where the authoritative package specification is stored". Was it referring to a persistent storage? Or to the in-memory storage? Anyway - in the new patch I have moved code that reads header to `pakcage-vc--desc->spec' function. This simplified the patch itself but also prompted me to consider an alternative approach, which I will elaborate on in the end of the message. >> + >> (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? I don't think I am getting this question. `pkg-spec' in function `package-vc-upgrade' was a new variable introduced by the previous patch. Function `package-vc-upgrade' had not `pkg-spec' before the patch. Was your question, perhaps, prompted by the fact that the patch was formatted in such a way it may seem it touches `package-vc--clone'? >> + (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. Agreed. In the new patch the `pkg-spec' is always in the same form. >> (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? Well, since I have used a different approach and this block is gone I will not add a comment. For posterity: I was binding in this way to avoid having a nil in the beginning of the `package-vc-slected-packages'. I guess that would make it slightly easier for anyone who's debugging this in the future. [...] When writing this new patch an idea occurred to me that installation a package with `package-vc-install-from-checkout' could store the location of the checkout directory in `package-vc-selected-packages', as a proper `pkg-spec' structure. That would remove a dichotomy that is present today: packages installed wich `package-vc-install' have their specs persisted between Emacs sessions, while packages installed with `package-vc-install-from-checkout' not. Please note, that one may get an impression (and I certainly did fell for it when I first started using `package-vc') from reading a doc string of `package-vc-checkout' that executing `package-vc-checkout' followed by `package-vc-install-from-checkout' will result with the same end state as `package-vc-install'. This is not true, as for the latter method `spec-spec' may be stored in `package-vc-selected-packages' while the former method will never add to `package-vc-selected-packages'. Except for the temporary binding with a (stub?) `pkg-spec'. Also, this could restore the semantics of property `:lisp-dir' in such a temporary `pkg-spec'. What I mean is that it is an absolute path when calling `package-vc--unpack-1' from `package-vc-install-from-checkout', while info node (emacs) Fetching Package Sources clearly states: A string providing the repository-relative name of the directory to use for loading the Lisp sources, which defaults to the root directory of the repository. One more benefit would be that the robustness issue (which still prevails in patches attached to this message) should be gone. Should you think it's a good idea I'd look for a guidance as to where such a value of the checkout directory be stored in a `pkg-spec'. Encode it as "file:///absolute/path/to/checkout" value of property `:url'? Or keep it as is (i.e., absolute path) in property `:lisp-dir' and just detect that in handlers and update relevant info? Or add a completely new property, say `:checkout-dir'? Last but not least: how important is to keep backward compatibility? Inside the master branch as well as across Emacs major versions. Cheers, PK --=-=-=--