From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.devel Subject: Re: feature/package+vc 04c4c578c7 3/4: Allow for packages to be installed directly from VCS Date: Fri, 21 Oct 2022 21:58:17 +0000 Message-ID: <871qr0kfeu.fsf@posteo.net> References: <164484721900.31751.1453162457552427931@vcs2.savannah.gnu.org> <20220214140020.04438C00891@vcs2.savannah.gnu.org> <87bkqmqpvb.fsf@posteo.net> <871qris3xb.fsf@gnus.org> <877d1aqoc1.fsf@posteo.net> <87edvhqdrb.fsf@gnus.org> <871qrh2hh6.fsf@posteo.net> <87mta5oyec.fsf@gnus.org> <87sfjx10x1.fsf@posteo.net> <875ygsp0ng.fsf@gnus.org> <87h70c9bu4.fsf@posteo.net> <874jw73cjy.fsf@posteo.net> <87edv72z11.fsf@posteo.net> <87czaq1i3k.fsf@posteo.net> <87fsfkhnhm.fsf@posteo.net> <87mt9s47f1.fsf@posteo.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="798"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Lars Ingebrigtsen , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Oct 22 00:28:31 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1om0VC-000AZU-WD for ged-emacs-devel@m.gmane-mx.org; Sat, 22 Oct 2022 00:28:31 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1om0EF-0004LU-LS; Fri, 21 Oct 2022 18:10:59 -0400 Original-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 1om02E-00037F-QB for emacs-devel@gnu.org; Fri, 21 Oct 2022 17:58:34 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1om02C-00054O-KX for emacs-devel@gnu.org; Fri, 21 Oct 2022 17:58:34 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id D7B24240101 for ; Fri, 21 Oct 2022 23:58:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1666389509; bh=Es4GwPkCucZJK4ZnCIHZTwF34kXmZvW8bL0WRx02M/g=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=OCGzstpd//+TNe0shfieV6AlOsrccAv/V4fWEj3yi+8BwnhBXeIClr93aRV2EtxTW zl49wycsmWNDhdwMQbqdVypFQh9f4xG3o2EoRMjXzMqVATKy0wH8FLgSTrVxhRPk84 HCDnw2GrDXDmJmZE7mh4iCipiddke+8JLW5gWeYWfcLzpQFpeUKF+l8CynG2wdVO0t CgLh0Y5iVEW8nP8RFHaSk4PoQkhEtiLM8DlHYHE22VQTqECqhXx3wgoiwXNtbMJj7f htLOvnmpDHfR0fl/S86t9dy3I8mWXH5ILyVmyn5So7jgyKzYWGwIzG6N6hAemN18qQ 1PXQSmuusvCAg== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4MvJJ03LjNz6tth; Fri, 21 Oct 2022 23:58:24 +0200 (CEST) In-Reply-To: (Stefan Monnier's message of "Wed, 19 Oct 2022 08:19:32 -0400") Autocrypt: addr=philipk@posteo.net; prefer-encrypt=nopreference; keydata= mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB Received-SPF: pass client-ip=185.67.36.66; envelope-from=philipk@posteo.net; helo=mout02.posteo.de 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: "Emacs-devel" Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:298234 Archived-At: --=-=-= Content-Type: text/plain Stefan Monnier writes: > Philip Kaludercic [2022-10-19 07:08:34] wrote: >> Stefan Monnier 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: --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0001-elpa-admin.el-elpaa-batch-make-all-packages-Generate.patch >From e4a2b7cdcf5fa62f301730db6b1e33d521d9d96f Mon Sep 17 00:00:00 2001 From: Philip Kaludercic 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 --=-=-= Content-Type: text/plain 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. --=-=-=--