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: Wed, 26 Oct 2022 07:11:03 +0000 Message-ID: <87zgdjqcu0.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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39219"; 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@gnu.org Wed Oct 26 09:13:03 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 1onab0-000A2h-UQ for ged-emacs-devel@m.gmane-mx.org; Wed, 26 Oct 2022 09:13:03 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1onaZE-00024o-HE; Wed, 26 Oct 2022 03:11:12 -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 1onaZD-00023C-Ao for emacs-devel@gnu.org; Wed, 26 Oct 2022 03:11:11 -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 1onaZB-00083l-8k for emacs-devel@gnu.org; Wed, 26 Oct 2022 03:11:11 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 0F555240105 for ; Wed, 26 Oct 2022 09:11:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1666768266; bh=8c/6WwctDcYunC20b9RgpZoogfU9nF8PGm47pt8Zhbk=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=K7GTnDFcvA971VmicTW0rJL+fdkqIabWzyBnjVIeFe1z4D3mQfuG9rghhRwpmiYef bnY8Sz4YAMK9oirZTZ8hchbRHs61z+EfqT2hpU9sySIcvEinrv+PGZDIfjxoDLtQea CFjivcZ+WpYDV8LAlJ7VBMgLbqJpduKCIwoI+fhWvxsUC9s4R6UlLoWKcMFnUllP2c r85fOcbIPRIWlD3f/kHsdGmzqY9oliUMDZIuKn0s0RFibpa1nAaDHyhsNOpCyxc62T eie2qL2lf5ZcJ2eE8c46PqYloPo9jAC2VbEB7RCkivUrWEl2WVWBCje60sOjCGzswV TeQeiPwsPfbFQ== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4My0Mr15jGz6tmj; Wed, 26 Oct 2022 09:11:04 +0200 (CEST) In-Reply-To: (Richard Stallman's message of "Tue, 25 Oct 2022 16:13:53 -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.66; envelope-from=philipk@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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_MSPIKE_H2=-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: , Original-Sender: "Emacs-devel" Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:298519 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. ]]] > > > > It would be better to offer a way that you can install your own > > > patches _in the released version_, which is probably the version you > > > were using and wrote the patches for, and then preserve these patches > > > when you install new released versions. > > > That is a long term goal, but if the foundation is to be merged before > > the next release, I have other issues that I'd like to address now and > > then return to this for Emacs 30. > > I'm not quite sure what that means -- what is the "foundation", and why > is there a hurry to merge it in? "Hurry" is the wrong way to look at it, I was just looking forward to having a basic feature like this added to Emacs 29. Of course this shouldn't be rushed, but I believe the branch is currently in a functional state that would be useful. > But there is a general principle that it is better to get the external > interfaces right before installing something new. Changing those > interfaces now won't require people to change habits; changing them > later could do so. > > 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. > Once we support choosing between the two repos for a package, the name > `package-vc-install' will be ambiguous -- it could fit either of those > two cases. It would not be a clear name to use. So let's not define > anything now with that name. The reason I chose this name is because of the symmetry to `package-install', and I still think this is nice. > I suggest the names `package-repo' and `package-dev-repo' for checking > out an ELPA package in these two ways, current repo and upstream/dev > repo. (I previously envisaged other names, but don't worry about > those.) Each of these names is clearer than `package-vc-install', and > they will make the distinction (choice of repo) clear too. In practice there is really no great difference between the "current repo" and a "upstream/dev repo". > 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", but "-repo" could do anything from opening the URL in an external browser or printing some message in the echo area.