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: Tue, 19 Sep 2023 09:34:03 -0500 Message-ID: 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; 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="26648"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 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 Tue Sep 19 16:35:07 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 1qiboh-0006Zp-2S for ged-emacs-devel@m.gmane-mx.org; Tue, 19 Sep 2023 16:35:07 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qibo7-00052o-7U; Tue, 19 Sep 2023 10:34:31 -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 1qibo4-00052c-4B for emacs-devel@gnu.org; Tue, 19 Sep 2023 10:34:28 -0400 Original-Received: from shrimp.cherry.relay.mailchannels.net ([23.83.223.164]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qibnv-0006Nk-9E for emacs-devel@gnu.org; Tue, 19 Sep 2023 10:34:27 -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 8DFAF84226D; Tue, 19 Sep 2023 14:34:15 +0000 (UTC) Original-Received: from pdx1-sub0-mail-a292.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 026A784130F; Tue, 19 Sep 2023 14:34:13 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1695134054; a=rsa-sha256; cv=none; b=A97YR57RJ2SEcCd9cWM9P6D2uSsFitIGCMzQMopPYSa7yOCwNyD9d2uhIJ5pvvOJbchTU3 oAejMf70dN93N/FCQ7QELn5LM5nxUkGFE2eQ9L8plTj+1T9Q+iThjuXLmUkLczTvTVgyf6 5MAD7wwF1dy/aZTxEGH1pGpbu6C5RylDUBMZ09dpFRpwM9cCv67wv4YruPOWx5emmbzaOt hfL/wF7d9DxIzKg1CaUngHxBnp9b4Xu9oZK9UfUTV4Psu5wFfNS9iMiQDlt4YYIdVkKS2v vtknrEC6/uDSyLbG+rxvMg5DVyf8QL8KdzUx19Q6O018u3xYXN7TW1FOKG+8Xg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1695134054; 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=cAC0h76Cx6I5hm411pcfGPSBcMtMlniC4u9IZ6Jo8PY=; b=IHpAyFxXR/bx22H8qzFLdUYrB+S0DoWOIEYgvjoU1n2ZHeT0g72nfj6ISkpDGgSb4w+F/i 3qGdCu2yHntGa4ZIIfBVa8tfIthYXEcpFKvWP/VwJYnMF/Hyf1MgIOy+eS2Q18wpAJfn1Q PBVgw/DyoyReIL15jcQ1ZzACqMvCEgQRR6E3rkMZRDx9oIsSoXjkX2pZHv8vvwCws4h3ep xB6Yh3QL20b8NjS+tbCA0oKzEHzo1hhDrsmx8s4wBI7xtBNXogH/KSc2bVfg+e7NmhoG6Z IpQMXiXVnAQDVtUSuIqf6iG8qbZz4PEKHH4eNTJxBLhU/kkcGDfkhtzPJUqv8w== ARC-Authentication-Results: i=1; rspamd-7d5dc8fd68-9kjhv; 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-Ski-Imminent: 0bd0f46016399262_1695134055372_1267548538 X-MC-Loop-Signature: 1695134055372:1813196563 X-MC-Ingress-Time: 1695134055372 Original-Received: from pdx1-sub0-mail-a292.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.97.244.81 (trex/6.9.1); Tue, 19 Sep 2023 14:34:15 +0000 Original-Received: from [10.66.0.178] (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)) (No client certificate requested) (Authenticated sender: adam@alphapapa.net) by pdx1-sub0-mail-a292.dreamhost.com (Postfix) with ESMTPSA id 4Rqkgn2R8szNm; Tue, 19 Sep 2023 07:34:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alphapapa.net; s=dreamhost; t=1695134053; bh=cAC0h76Cx6I5hm411pcfGPSBcMtMlniC4u9IZ6Jo8PY=; h=Date:Subject:To:Cc:From:Content-Type:Content-Transfer-Encoding; b=DlGQXFpWb0sZAi41XQ3sgdjsmYEM+JCk+P/cSfr2y3brsubu0WCufZfamQy4h9UGg U1dny1sD7A0BPESpJ0GXThqt8dgNq1t56fMrLBSPYBbsTCaR21Vtc8hkiuOOJx/gMV q+EgTMPVl97ZE8/mvUxpHOC5qB1CoB15nl559r7wKq0cI9lV4CNzb8dsOsVIHL/C+I yjEOnTpz/3ZLMQ82wIoIOaBUCrnVs7k372rCYkV1eQ4yUjv8inxo3WPTYjDxW/YQ/s SR/TfxXCAtXlUAwW/HXALriIaKQ4BFXHgS9vMoU/VfiLs5aGilj3VFD7pAPSkjP+Nu IbGWaAbl6ieAw== Content-Language: en-US In-Reply-To: <87cyyeb7c0.fsf@posteo.net> Received-SPF: neutral client-ip=23.83.223.164; envelope-from=adam@alphapapa.net; helo=shrimp.cherry.relay.mailchannels.net X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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, NICE_REPLY_A=-1.473, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779 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:310773 Archived-At: 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". 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, "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. >> 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. 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.) Do these explanations clarify what I mean? Let me know if I need to try again. :) --Adam