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: Wed, 20 Sep 2023 08:13:41 +0000 Message-ID: <87ttrp8doq.fsf@posteo.net> References: <87il86lis7.fsf@breatheoutbreathe.in> <87h6nqbkmq.fsf@posteo.net> <445b1a43-23a8-f6f3-08f6-82db6ed4adc6@alphapapa.net> <87cyyeb7c0.fsf@posteo.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="22427"; 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 Wed Sep 20 10:14:50 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 1qisMD-0005gf-Un for ged-emacs-devel@m.gmane-mx.org; Wed, 20 Sep 2023 10:14:50 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qisLI-0002Fo-H6; Wed, 20 Sep 2023 04:13:52 -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 1qisLG-0002EY-Cs for emacs-devel@gnu.org; Wed, 20 Sep 2023 04:13:50 -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 1qisLD-0004Bg-S2 for emacs-devel@gnu.org; Wed, 20 Sep 2023 04:13:50 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id C4997240109 for ; Wed, 20 Sep 2023 10:13:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1695197624; bh=YV15UJKvU9oVZERq9nwRK836fvW0r8X2t2uNZ5H+ssY=; h=From:To:Cc:Subject:Autocrypt:Date:Message-ID:MIME-Version:From; b=CQZMrgTpJOBnHQlbfSWeiV1Z69TmaigLJs2JS9wTcPkX50q4n6Zr96qnFdrtvWEao YIKmjL/5qmjcqD3sIbr91xn0myT6NyYaTAHALxiisy30IBuIq9/HqcMrsKoYH3CHHq sMW9rsHyWPxHoXNhBttlN3wUHKJc11Tw8/KsqKb/VmvZn9Tqr9Lbqw4UnmKWtQVL/N zVQAWiz/K54A7tQBRefUepER3iunpCy6JG5TQ/haFTpJKmfoN1MPbhztLakeP+0xev TFUV+TRZpJ8nV5Isqy2g5diD+Z/k/EzzHVDL4gr93xOdJsBN/vh9lRaRuFsP87m/2+ i8n63yvWfLsEA== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RrBBF6wwsz6v9b; Wed, 20 Sep 2023 10:13:41 +0200 (CEST) In-Reply-To: (Adam Porter's message of "Tue, 19 Sep 2023 09:34:03 -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.66; envelope-from=philipk@posteo.net; helo=mout02.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:310806 Archived-At: Adam Porter writes: > On 9/19/23 08:50, Philip Kaludercic wrote: > >>> An alternative would be to follow Quelpa's example: rather than >>> loading the package directly from the git repository's directory, the >>> package's files could be copied into a new directory in the elpa/ >>> directory, and Emacs could load the package from there. >>> >>> As a developer, I would prefer that approach, because I don't usually >>> want Emacs to load whatever commit I may have checked out in a >>> package's repository. I want to install a commit of a package into my >>> Emacs configuration and have that one loaded until I install a >>> different one. >> Isn't this workflow already supported by `package-install-file'? >> And >> otherwise, there wouldn't be much of a point to just replicate the >> functionality of an existing package manager. > > That doesn't seem to do the same thing: it doesn't install from a git > repo, per se, but from local files or directories: > > (package-install-file FILE) > > Install a package from FILE. > The file can either be a tar file, an Emacs Lisp file, or a > directory. > > What I like to do is to install the package from the git repo as a, > well, "normal package," i.e. as if it were installed from ELPA. > That's how Quelpa works: it produces, > e.g. "~/.emacs.d/elpa/PACKAGE-VERSION/PACKAGE{,...}.el". I don't have > to have a local clone of the repo first. > > (Also, the name of the command suggests that it only installs from > files rather than directories; I didn't even realize it could install > from directories until now.) > >>> In other words, the way package-vc-install currently works leaves me >>> vulnerable to this scenario: >>> >>> 1. I use package-vc-install to install one of my packages from its >>> local repository directory. >>> 2. I check out a feature branch of that package to work on a new >>> feature, saving some files but not loading any of the changed code. >>> 3. I restart Emacs (e.g. maybe I shut down the system and turned it >>> back on the next day). >>> 4. That work-in-progress feature branch of my package gets loaded >>> into Emacs automatically (which may be entirely broken, being a WIP). >> I understand your issue, but anecdotally, I can also give an example >> where I wanted to change some functionality, by M-x find-function'ing >> the source buffer and then loosing the change after upgrading the >> package. > > 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. > 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? > "M-x package-delete" shouldn't be wiping out > user data. Development on packages should be done on clones stored > outside of "~/.emacs.d", e.g. in "~/src" or whatever one uses. IMHO, > of course--Emacs is all about user freedom--yet I think we should > encourage the better practices. I don't see it that way, but the technical background for this decision is that source packages -- written with the intention of loading the source code directly from the checkout -- should be loadable without having to require package-vc, since package-vc is just an extension of package.el that allows for an alternative way of installing packages. >>> Whereas if I use Quelpa, it installs the files a package's recipe >>> specifies into the expected location in the elpa/ directory, and that >>> remains independent of whatever I may have checked out in the >>> package's local git directory. My Emacs configuration and installed >>> packages remain consistent regardless of whatever in-between state I >>> may have left a package's repository in. >>> >>> Philip, would you be willing to consider switching to that model for >>> package-vc-install, or offering it as an option? >> 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. > Then if the user wants to modify the package, he should either a) use > a local clone wherever he keeps such projects, or b) configure > package-vc to clone the repo to such a directory, and then a command > could automate finding the source files in that directory rather than > the ones in package-user-dir which are loaded into Emacs. (IIRC > Straight, for example, does something like this, but I don't use it > myself.) To my understanding Straight maintains all packages in separate repositories, then symlinks the files that are to be loaded. So just like with package-vc, you always have direct access to the source code under VC. > Do these explanations clarify what I mean? Let me know if I need to > try again. :) 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. > --Adam