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: Tue, 01 Nov 2022 14:54:47 +0000 Message-ID: <87tu3iend4.fsf@posteo.net> References: <164484721900.31751.1453162457552427931@vcs2.savannah.gnu.org> <20220214140020.04438C00891@vcs2.savannah.gnu.org> <87bkqmqpvb.fsf@posteo.net> <87edv96q4j.fsf@posteo.net> <83tu455a5s.fsf@gnu.org> <87a65v2ytp.fsf@posteo.net> <834jw33rmx.fsf@gnu.org> <87pmer0xtz.fsf@posteo.net> <83wn8z2aze.fsf@gnu.org> <878rle1i0k.fsf@posteo.net> <87ilkelc10.fsf@posteo.net> <878rl6syg8.fsf@posteo.net> <87zgdjqcu0.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="38882"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 01 17:09:26 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 1optpM-0009uM-Fo for ged-emacs-devel@m.gmane-mx.org; Tue, 01 Nov 2022 17:09:24 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1opsfG-0006Qb-Mc; Tue, 01 Nov 2022 10:54:54 -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 1opsfE-0006QP-Q9 for emacs-devel@gnu.org; Tue, 01 Nov 2022 10:54:52 -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 1opsfC-000261-II for emacs-devel@gnu.org; Tue, 01 Nov 2022 10:54:52 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id AE61024002A for ; Tue, 1 Nov 2022 15:54:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1667314488; bh=yTjdM6VyWQjcEl8SCEyl89hjsc2CybcNYaeuWxwlus4=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=Z2ufBCIPpiWUVdrL2RBLX4mZ/YsYxiC6CZvFkHCiSCkHXeybL9Fi88mcaLu1bG7qu NT6DG7q4EU2LYfW5Bw6w3BHc4MJWquMvTWVXf3IYdfIQhsebYFiMcyF36AQhkQCKPQ 6sjnADfwGqwqZNevKBGYEDglLYMvwHLsz1uUFFCNmumouy50+0IWREzIURtrGqlZuC qQFQ1IRz7ZGM15yj8PHl846LFScVOG3SOFOG8AqRPEyk6jy2EoSgo3WmJJpDFh5Mjv msLxDVW7pzeF0i4AV+e9RmeJgPpff3f0wmA2rywfZ7eIQC3+gI7ukkKGGuHv9Z+3PV BfSUHMyfZHkog== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4N1tN81m4Pz9rxF; Tue, 1 Nov 2022 15:54:47 +0100 (CET) In-Reply-To: (Richard Stallman's message of "Tue, 01 Nov 2022 07:10:06 -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.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, 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+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:298936 Archived-At: Richard Stallman writes: > [[[ To any NSA and FBI agents reading my email: please consider ]]] > [[[ whether defending the US Constitution against all enemies, ]]] > [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > > > I'm not quite sure what that means -- what is the "foundation", and why > > > is there a hurry to merge it in? > > Of course this > > shouldn't be rushed, but I believe the branch is currently in a > > functional state that would be useful. > > That may be true -- I don't know, so I won't dispute it. > However, before we merge it in we should get the command > interface right. FYI since our last exchange I have implemented the features necessary to check out the commit used to create the tarball that ELPA server would distribute. This is done when you invoke `package-vc-install' with a prefix argument. > > > The code for checking out the current-version repo of an ELPA package > > > should be very little different from the code for checking out the > > > upstream repo. If the latter is already working, getting the former > > > to work equally well shouldn't take long. Would you please do that? > > > It can be done, but I believe it would be best to add those kinds of > > annotations to the server side (elpa-admin.el). The issue is that > > figuring out what version was used to release a package is non-trivial > > using just vc. > > I find it hard to understand that last sentence. What does it mean, > "what version was used to release a package"? I meant to say "revision", sorry about that. But as I said above, this has now already been implemented. > Do you mean, "what version _in the upstream repo_ was copied into the > ELPA repo"? If so, I think that is a spurious problem -- we don't > need to know which upstream version. At least, not for this purpose. > It might be useful to keep track of that for some other purpose; if > so, I have nothing against doing so. But it isn't related to this > feature. > > ELPA has its own repo. By definition, the current version of the > package its latest version of in the ELPA repo. To get the package > source in a repo, for the current ELPA version, should simply check it > out from the ELPA repo. This has nothing to do with the ELPA repo. > > These two operations (check out from ELPA repo, and check out from > upstream repo) are different in purpose. It is important to avoid > confusion about whether the checkout contains the current version > or the upstream repo. I have my doubts as to how significant of a difference these two things are. But this isn't to be decided in package-vc.el anyway, instead the package archive (in our case GNU ELPA and NonGNU ELPA) generates a list of package specifications, which can either point upstream or to ELPA. > So they should have different command names. There are more and more packages that are automatically synchronised, as is the case by default with NonGNU ELPA. In that case, there is no significant difference between the two, and introducing such a thing would just bring about confusion. What can be argued is that packages from GNU ELPA that are not automatically synchronised ought to point to elpa.git. But as I have said, that is a decision that can be made at any point, unrelated to package-vc.el, as this is just the "input" that an ELPA server provides. > Also, the results should be distinguishable by directory name. A > checkout from the upstream repo should have `upstream' in its name, > while a checkout from the ELPA repo should have `current' in its name. > This too will help users avoid misremembering which version they > are operating on. Is this a point related to the separation of upstream and ELPA repositories, or one in general. > I think we should separate checking out the upstream source from a > repo and "installing" for use by default in your Emacs. There are > several reasons to want to see the upstream source, different > scenarios. > * A user might want to start using the upstream version by default. > > * A user might want to work on changes in the upstream version > and try those changes from time to time, but not most of the time. > > * A user who has started using the upstream version by default > might wish to disable use of that version because it has some flaw, > and reemable it later. > > So there needs to be a way to enable and disable use of a specific > ELPA version checkout of a package. I believe that package.el already supports this via `package-load-list'. > I think we should separate the operations of checking out a version > from a repo, and enabling or disabling that version for use by Emacs. > > > > I think `package-dev-repo' would be the command now called > > > `package-vc-install'. > > > I am fine with renaming the file "package-vc" to "package-dev", but the > > "-repo" suffix is not clear to me. "-install" is clear in the sense > > that it will fetch and activate the package, just like > > "package-install", > > How about `checkout' instead of `repo'? `package-checkout' to check > out from the ELPA repo, and either `package-upstream-checkout' or > `package-dev-checkout' for the upstream repo. As Stephan has pointed out that "-checkout" is misleading since it sounds like a command that would just clone the repository without activating it as a package. FWIW this is a fine functionality to have and would be trivial to implement. > We could also have `package-enable-version' and `package-disable-version' > to enable and disable actual use of a package checkout by Emacs. > > Is it feasible to specify which version of which package by selecting > a directory containing a checkout, or by putting point in a list of > such checkouts? That would be a convenient interface, I think. As mentioned above, I believe that `package-load-list' is the right tool for the job. In general, package-vc.el is just an alternative method if fetching and initialising a package, the rest is just done taken care of by package.el, that isn't too concerned about where the package came from.