From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Richard Stallman 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 07:10:06 -0400 Message-ID: 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> Reply-To: rms@gnu.org Content-Type: text/plain; charset=Utf-8 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20664"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Philip Kaludercic 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 12:11:06 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 1oppAg-0005CD-5k for ged-emacs-devel@m.gmane-mx.org; Tue, 01 Nov 2022 12:11:06 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1opp9m-0001Sn-IC; Tue, 01 Nov 2022 07:10:10 -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 1opp9k-0001Qd-S5 for emacs-devel@gnu.org; Tue, 01 Nov 2022 07:10:08 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1opp9j-0006ez-5o; Tue, 01 Nov 2022 07:10:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=Date:References:Subject:In-Reply-To:To:From: mime-version; bh=j3TmSDdzjHrSTn6/XwPP7RI+IKiuJth2fV3sm9YCXHY=; b=HjPT+qItgmIk hvTS+d1EJe7QQjEbkMVGPa1EX/7crrR/VVbxuoVHbe4YrULvn9mgaL7+jdVBsrosqV8+AXViQtopf NL+Xos1QjCouDj9eGZigEdHOFKVEIN6TQZJ+QjcXZ+AO6F8Wqp37U6XbJha3kfmd8vZiWpmbDFdKq /ZteZXmZEBfRUM2cA9ioKiSa8T/kngefyayZmEZ4ahLcroUN9yKz8ilKY/xZoozRClCL0ahcZ/Ed8 +CJXy3JcFJL5frVqbt/k88V0DK3HCIyz1sZ2GL1Zsp2bE597XytXc4+OGiF33cQY9r/YUE3Puyupg Yqk+IBTZl8cUMDSejbXE2g==; Original-Received: from rms by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1opp9i-0005Py-Ky; Tue, 01 Nov 2022 07:10:06 -0400 In-Reply-To: <87zgdjqcu0.fsf@posteo.net> (message from Philip Kaludercic on Wed, 26 Oct 2022 07:11:03 +0000) 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:298927 Archived-At: [[[ 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. > > 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"? 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. So they should have different command names. 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. 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 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. 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. -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)