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: [package-vc] Consider cleaning up files from install process Date: Sat, 07 Oct 2023 13:31:27 +0000 Message-ID: <87pm1qpnio.fsf@posteo.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> <560eeace-6c97-40e2-988b-3b1019f24677@alphapapa.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7232"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Joseph Turner , Emacs Devel Mailing List To: Adam Porter , Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Oct 07 15:32:31 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 1qp7Pz-0001du-3I for ged-emacs-devel@m.gmane-mx.org; Sat, 07 Oct 2023 15:32:31 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qp7P9-0002yP-CE; Sat, 07 Oct 2023 09:31:39 -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 1qp7P5-0002wM-IG for emacs-devel@gnu.org; Sat, 07 Oct 2023 09:31:35 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qp7P2-0008Dj-KT for emacs-devel@gnu.org; Sat, 07 Oct 2023 09:31:35 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 40145240027 for ; Sat, 7 Oct 2023 15:31:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1696685488; bh=azAO1mjn/QGRQkFNOVEFf9PXO5VsaSp1Woitc1+IJkQ=; h=From:To:Cc:Subject:Autocrypt:Date:Message-ID:MIME-Version:From; b=j5vKd1tyq0KLpEWuCt5xq8ZdR7/dy6R+wO7cfx0FE1xZKov+5Ob4daNsS8VDuTYHP fE9uQ6a2qnPukh96+Wa7si9wfb+St+BP9dCClMiwp9yNqAUm7SfCoGzFNouY94gTlg FbJPB21beAL8auf3eA2XVfQVTliIQT0rjTDl9QwUyxmfa5MdtqUDz8n5dLsR6wi2oQ 8xrP+u1IrWGYbMqGdWBfcPA3qFQdwHGlGYn0vX1Yj7XA/BLMxAxQq9+fTaOhxOhA38 2hPdaGWgNZlY2FIB78Oc9uN1Ix7ns2p0+B+NFJq0TEV0dcfHXHi2J4ajD56TaO/2HL XPvC+Dv9Xnhuw== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4S2mR33kmFz6twZ; Sat, 7 Oct 2023 15:31:27 +0200 (CEST) In-Reply-To: <560eeace-6c97-40e2-988b-3b1019f24677@alphapapa.net> (Adam Porter's message of "Sat, 7 Oct 2023 02:52:34 -0500") 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 Received-SPF: pass client-ip=185.67.36.65; envelope-from=philipk@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=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: , 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:311344 Archived-At: Adam Porter writes: > 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. It is not that I don't get your argument, I think it is a fair point; my issue is that this ends up just being a discussion of anecdotal use-cases. I can point out that if I check out a feature branch, I would like to use it, that if I modify a function, I'd like to test it. If I just want to hack on something that I am not using, I wouldn't be using package-vc. But I suspect that this doesn't mean that much to you, because we just have different workflows. >>> 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 don't think I agree. Just because a user doesn't know what "apt install coreutils" does, doesn't mean that the system should have to be resilient to a "rm -rf {,/usr{,/local}}/bin". It would be a different matter if the user could reasonably assume that elpa/ is a cache directory, but I don't see why that should be the case. > (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.) That is something i wouldn't recommend, but mostly because I avoid adding auto-generated files to a git repository. >>>> 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. Currently I wouldn't want to add this to package-vc itself, but I could imagine adding a package to ELPA that would provide the functionality with all the related user 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. The background for package-vc is that it is a further iteration on my site-lisp package. I wrote that to automatically manage (add to `load-path', byte-compile, scrape for autoloads) my packages, that I load directly from their Git repositories, because I want M-x find-function to work. Following Stefan Monnier advice, the approach with package-vc was to delegate loading the package.el, and add an alternative "back-end" for fetching packages + means for contributing local changes back upstream (package-vc-prepare-patch, and why package-vc-install fetches an index of package specifications from ELPA servers). Installing packages that are not listed in GNU or NonGNU ELPA is neat, but not my focus behind developing the package. That remains streamlining the process of contributing to packages and hacking directly on the code that is being loaded. > Thanks for your help, > Adam