From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Adam Porter Newsgroups: gmane.emacs.devel Subject: Re: [package-vc] Consider cleaning up files from install process Date: Sat, 7 Oct 2023 02:52:34 -0500 Message-ID: <560eeace-6c97-40e2-988b-3b1019f24677@alphapapa.net> References: <87il86lis7.fsf@breatheoutbreathe.in> <87h6nqbkmq.fsf@posteo.net> <445b1a43-23a8-f6f3-08f6-82db6ed4adc6@alphapapa.net> <87cyyeb7c0.fsf@posteo.net> <87ttrp8doq.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8136"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: Joseph Turner , Emacs Devel Mailing List To: Philip Kaludercic Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Oct 07 09:53:55 2023 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 1qp28I-0001th-Nc for ged-emacs-devel@m.gmane-mx.org; Sat, 07 Oct 2023 09:53:55 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qp27N-0005ot-E1; Sat, 07 Oct 2023 03:52:57 -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 1qp27L-0005oR-EY for emacs-devel@gnu.org; Sat, 07 Oct 2023 03:52:55 -0400 Original-Received: from bird.elm.relay.mailchannels.net ([23.83.212.17]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qp27E-0000QS-2o for emacs-devel@gnu.org; Sat, 07 Oct 2023 03:52:55 -0400 X-Sender-Id: dreamhost|x-authsender|adam@alphapapa.net Original-Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 1A008901C6D; Sat, 7 Oct 2023 07:52:46 +0000 (UTC) Original-Received: from pdx1-sub0-mail-a314.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id A4777901CE0; Sat, 7 Oct 2023 07:52:45 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1696665165; a=rsa-sha256; cv=none; b=hUUA5sInOinC4XUe8o1bhndIWSmWNV+b05LmuiBC/zxiFFj2fUbLjbJJffwLbv0mCA9NfI ojU8Pcn+PlLsnQ+W4TqOVxPX02TpozhVA6uPHE8jqhLQ8T3qF60mlEdiQXvmq5ORR64VA0 ab+5MNHB5gqI0DkCnxEz1ye05PXtHRuoMlwR7YfKKicYC9jlJwwK89iweHx0vUKUfwVHiV 9FpXEfpMWekO5qa6OOvr5GKEnheck+P2dFFn4Hyd922Mg9Dh8yP6fcrjYOGYHE7CZTDEIP QBnu140VMWQCSj+6hvW9E3BFDUgjiRIsPYiX/NY/I9kdPAccvKSeDQB6Hm/0aw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1696665165; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=E9KH+Bb02knl54eMBNkcykZiuKhzOdxSRZ0Bt/7CMFs=; b=gZ0AoN9omu5CJTqDVMl4I6rwKxgpvX6JmlXUHrHwhZ8UGfwiiBliMT8WlffH+PLXX5xuuY OFclbJ7d9KyliYJjY57DsXDC/PnGLZH1A6UpiDw5CZsiWQL2HRPxmkmLrlE5DDujRW5oYx MdBxGHxI6YCst37G4ciQWTuger3kDUSg19A9hhCRTG9Bs071jE+xXvtCPZ/+UPyP1d0cK6 ENuCfvEx5rpWNKELqnv1OyVNgTAZIbRTCBbZXBTrwSO6zJroH6dRaj9b70ciXImI6XHG/p lutUf4myDWvALyCYjvq09CyTHGJnR4Ba4+yAfKJHLarXGhjw+SKlpcgdvdqVeQ== ARC-Authentication-Results: i=1; rspamd-7d5dc8fd68-rskhg; auth=pass smtp.auth=dreamhost smtp.mailfrom=adam@alphapapa.net X-Sender-Id: dreamhost|x-authsender|adam@alphapapa.net X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|adam@alphapapa.net X-MailChannels-Auth-Id: dreamhost X-Invention-Daffy: 5d809fd96a06d887_1696665165921_160733778 X-MC-Loop-Signature: 1696665165921:1994439801 X-MC-Ingress-Time: 1696665165921 Original-Received: from pdx1-sub0-mail-a314.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.112.191.222 (trex/6.9.1); Sat, 07 Oct 2023 07:52:45 +0000 Original-Received: from [10.66.1.110] (unknown [91.193.232.98]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: adam@alphapapa.net) by pdx1-sub0-mail-a314.dreamhost.com (Postfix) with ESMTPSA id 4S2cwF0Ktpz7G; Sat, 7 Oct 2023 00:52:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alphapapa.net; s=dreamhost; t=1696665165; bh=E9KH+Bb02knl54eMBNkcykZiuKhzOdxSRZ0Bt/7CMFs=; h=Date:Subject:To:Cc:From:Content-Type:Content-Transfer-Encoding; b=k9UwOQ8IXsi8cV6UwuLxucvkTQrcMJZNaPiLJb3uAe9t4vQcsWObhJInhhNjbhCZU 6buCycnz65b9W9Ln1MeMDQGptS/qQg2NR89CEdxh3P5HqnP/3VSDJEk9HUzPNyiPVI S2a6trIMz6tRu67nFQHp942C9NXjZSA8E0hvZkFFXtPPEVPryKu8JJeN3sgaE4vy9p itmZfTVwxE/qHMwZFFgGjhB5Gr7fWmBkKE+zUTD/UWnPbVIU4fcImzzuMiqE2jG/kZ CqbzwbJxw7J7jD4x8EwJTLWsT91PdvIL6/4g9utZuiKjuHEM2vfEmjq9yurxu/C8Zu Ucorw0Z15w2UA== Content-Language: en-US In-Reply-To: <87ttrp8doq.fsf@posteo.net> Received-SPF: neutral client-ip=23.83.212.17; envelope-from=adam@alphapapa.net; helo=bird.elm.relay.mailchannels.net 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_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01 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: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:311340 Archived-At: Hi Philip, On 9/20/23 03:13, Philip Kaludercic wrote: >> IMHO that seems like a sort of user-error, to leave uncommitted >> changes in a repo that's under the control of a system that doesn't >> take such changes into account when operating on the repo. IOW, if I >> install a package with command package-FOO, I expect the files it >> makes to be under its purview, not mine; they are not my personal data >> files, but belong to Emacs and its package.el library, the same as if >> I used "M-x package-install". > > I don't believe in these kinds of distinctions. I can change what I > want, the only question I have to keep in mind is what the chances of > loosing these changes is going to be. I think I understand what you mean. However, that seems to conflict with the idea of loading packages directly from git worktrees, regardless of their status. That is, when I install a package into my Emacs configuration, I intend for the version I installed to be available when I start Emacs, not whatever state I might have left the repository in when I last touched it. If I had last checked out an in-progress feature branch and then shut down my computer, I wouldn't want Emacs to attempt to load that next time. >> To put it another way, it seems like a bit of an anti-pattern to >> develop a package that's stored in "~/.emacs.d/elpa"--that directory >> is supposed to be for installed packages' files, and it should be safe >> to wipe that directory out at any time and reinstall packages from >> their sources--after all, > > Is that documented anywhere? I know it can be done, if your > configuration is written accordingly, but if you see installed packages > as not being part of your domain, then transgressing layers of > abstraction and accessing, then deleting the "internal" representation > of package.el would seem to also be wrong? I don't know if that idea is documented anywhere, but it seems implicit to me by reason of users not necessarily needing to be aware of what files and directories get created when installing a package. If a user only used the package-install and package-delete commands, and didn't look at the filesystem or messages output, he wouldn't know nor care where the packages' files were. (I regularly advocate committing one's "elpa/" directory to git along with one's "init.el", and in so doing I've learned how many users aren't aware of how it all works.) >>> Can you describe the interface you are imagining. From what I >>> understand, it should be possible to reproduce what you need by >>> combining `package-vc-checkout' and `package-install-file'? >> >> Well, I would expect it to act similarly to Quelpa: >> >> 1. Clone the git repo (shallowly, at least by default) to a directory >> (perhaps a temporary one, but at least one stored in the appropriate >> XDG cache directory, outside of user-emacs-directory). >> >> 2. Call package-install-file on that worktree. >> >> 3. The package ends up installed into package-user-dir as if it were >> installed with package-install from ELPA. > > How does this look like: > > --8<---------------cut here---------------start------------->8--- > (defun package-vc-install-copy (pkg-desc) > "Fetch the package sources of PKG-DESC and install a copy." > (interactive (list (package-vc--read-package-desc "Fetch package source: "))) > (let* ((copy (copy-package-desc pkg-desc)) > (package-dir (expand-file-name > (symbol-name (package-desc-name pkg-desc)) > (make-temp-file "package-vc-" t))) > (package-vc-register-as-project nil)) > (setf (package-desc-dir copy) package-dir) > (save-window-excursion > (package-vc-checkout pkg-desc package-dir) > (package-install-from-buffer)))) > --8<---------------cut here---------------end--------------->8--- > > I'd ideally pass :last-release to package-vc-checkout, but I have > detected a bug with this setup that should be fixed. I tested that command in a clean Emacs 29.1, and it seems to work well. Thanks. The only suggestion I have would be for an optional persistent directory used for keeping the git repositories around as a cache (i.e. outside of user-emacs-directory, likely in $XDG_CACHE_HOME), so that when upgrading the package, the whole repo wouldn't need to be cloned again, e.g. Quelpa configures this in the `quelpa-dir' option. > The main question I have is what advantage or disadvantage this would > provide over Quelpa? The functionality you describe misses the point of > what I see to be the point of package-vc, as it wasn't written to be a > replacement of Straight or Quelpa (I have never used either of the two), > but just as a tool to streamline fetching and preparing packages > directly from source code repositories. The advantage over Quelpa would simply be to not require Quelpa. :) I'd like for this functionality to be built-in to Emacs. I thought that's what package-vc was basically intended to do (i.e. give a user a git repo URL and he can install the package into his Emacs with a single command, as if he had cloned it manually and ran package-install on it), but maybe I misunderstood. Thanks for your help, Adam