Re: feature/package+vc 04c4c578c7 3/4: Allow for packages to be installed directly from VCS

[Philip Kaludercic <philipk@posteo.net>]

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

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

> Philip Kaludercic [2022-10-19 07:08:34] wrote:
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>>> I have pushed a first draft and it appears to work.  It doesn't yet
>>>> handle all attribute (such as :doc), but that should be doable when I
>>>> find the time.
>>> Side note: installing packages from Git (like what you're implementing
>>> in the `package+vc` branch) is already one of the functionalities
>>> supported by `elpa-admin.el` so it would be good to try and share/reuse
>>> that code as much as possible.
>> That is only possible insofar I don't have to rely on Git features,
>> since package-vc intends to be VC-generic.
>
> I'm thinking of things like the code that handles `:doc` or `:make`.
> These don't care about Git.

For something like :make to work, we would also require :renames, right?
But if that is added, then the version control could break.

> I don't think that the code in `elpa-admin.el` can be used as-is, but it
> would be good to try and change them in tandem (maybe by extracting the
> common code into some new file?).
>
>>> Actually part of `elpa-admin.el` might also be helpful for the
>>> ELPA-bundling feature.
>>> So we should move more of `elpa-admin.el` into Emacs's own code.
>> As part of `package-vc' or as a new module?
>
> I think either way is fine.  The whole `elpa-admin.el` contains things
> that are irrelevant to Emacs itself, so we'll likely keep a separate
> file like that, but the code that's useful for other uses
> (i.e. package-vc and/or bundled-ELPA) should be moved out (tho
> elpa-admin.el has to be backward compatible to some extent, so we'll
> have to keep a "local" copy of whatever is moved to a common file
> hosted in emacs.git, at least for a few years).

How does this look like:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-elpa-admin.el-elpaa-batch-make-all-packages-Generate.patch --]
[-- Type: text/x-patch, Size: 1834 bytes --]

From e4a2b7cdcf5fa62f301730db6b1e33d521d9d96f Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Fri, 21 Oct 2022 23:18:30 +0200
Subject: [PATCH] * elpa-admin.el (elpaa-batch-make-all-packages): Generate
 elpa-packages.eld

---
 elpa-admin.el | 18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/elpa-admin.el b/elpa-admin.el
index 054c9bda86..fc08dcb540 100644
--- a/elpa-admin.el
+++ b/elpa-admin.el
@@ -764,11 +764,25 @@ of the current `process-environment'.  Return the modified copy."
 
 (defun elpaa-batch-make-all-packages (&rest _)
   "Check all the packages and build the relevant new tarballs."
-  (let* ((specs (elpaa--get-specs)))
+  (let* ((git-sv "https://git.sv.gnu.org/")
+         (specs (elpaa--get-specs)))
     (dolist (spec specs)
       (condition-case err
           (elpaa--make-one-package spec)
-        (error (message "Build error for %s: %S" (car spec) err))))))
+        (error (message "Build error for %s: %S" (car spec) err))))
+    (with-temp-buffer
+      ;; Remove and compress the contents of the "elpa-packages"
+      (let ((standard-output (current-buffer)))
+        (dolist (spec specs)
+          (when (eq (cadr spec) :core)  ;handle "core" packages
+            (setf (cdr spec)
+                  (append
+                   (list :url (format "%s/git/%s" git-sv elpaa--gitrepo)
+                         :branch (concat elpaa--branch-prefix (car spec)))
+                   (cdddr spec)))))
+        (prin1 specs))
+      (write-region nil nil (expand-file-name "elpa-packages.eld" elpaa--release-subdir))
+      (write-region nil nil (expand-file-name "elpa-packages.eld" elpaa--devel-subdir)))))
 
 (defun elpaa-batch-make-one-package (&rest _)
   "Build the new tarballs (if needed) for one particular package."
-- 
2.38.0


[-- Attachment #3: Type: text/plain, Size: 248 bytes --]


It currently makes the assumption that :core is the first element in the
property list for each package specification.  This appears to be the
convention and makes the code simpler, but if you think it is not
justified, that part can be reworked.