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: Sun, 23 Oct 2022 09:04:23 +0000 Message-ID: <878rl6syg8.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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2759"; 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 Mon Oct 24 09:03:56 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 1omrV6-0000Q3-FJ for ged-emacs-devel@m.gmane-mx.org; Mon, 24 Oct 2022 09:03:56 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1omlDy-0000Ts-LX for ged-emacs-devel@m.gmane-mx.org; Sun, 23 Oct 2022 20:21:50 -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 1omWuE-0007C0-0k for emacs-devel@gnu.org; Sun, 23 Oct 2022 05:04:30 -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 1omWuB-0001PN-PF for emacs-devel@gnu.org; Sun, 23 Oct 2022 05:04:29 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 5ED97240109 for ; Sun, 23 Oct 2022 11:04:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1666515865; bh=8WOg/uQJO/aE+TxtqI51uS6ss5OH2s/jDg9pv5Ppwqs=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=BGyCTnjekSDkxyVApelb+zxJQp/yvhtbi7iVpTIwhD6eRfP98AB2itYnKYsJvLeqO Z6vByLLMIkm60lqj4VDTxOCbKot8E0ePP/hlz45JRYFTqep1gLUrguqWjIXPiKgNZ2 mAQsZ5/OOSQO9qwt7EqYSkM/OSJ7J03qWUx2RKVmuSGsv9adwliW2O+ebkna9N3hf0 2EoIV0wGBUeT3EQ8CGl3J7PbQesxyOaxPFK8xo/qgpKuUv32c9MbiyawOMWY7MYGq9 +xKyvpqVNFe5HjX7Td+DkkIHKDfVvvZkXg6AniFURa6lpww/BZAd1OdFxYRt3I6W2U S9PVjMFN4HOFA== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4MwC201SSLz6tmY; Sun, 23 Oct 2022 11:04:24 +0200 (CEST) In-Reply-To: (Richard Stallman's message of "Sat, 22 Oct 2022 15:59:31 -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_DNSWL_NONE=-0.0001, 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: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:298348 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. ]]] > > > > If the main purpose of this feature is for people to test, debug and > > > develop the development version, I think it is wiser not to speak > > > of "installing" from VCS. > > > Not necessarily, another advantage might include the ability to maintain > > personal changes that don't get overridden by updates. > > That would be a useful feature. But I think it would be unfortunate > (and not what users want) to tell them, "To make and save your own > patches, switch to the development version of the package." > > 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. > > In general I would like to see something like "package-vc" being > > regarded as a means to make software freedom more practical/perceptible. > > That is a good general goal, but I don't think it applies to this > question. Whether you want to try a development version is one > question; whether you want to make patches (and desire to preserve > them across updates) is another question. Let's make the latter feature > available for the reeased package also. > > I understand that may be some extra work. However, merging your local > patches with upgrades is not always going to be trivial and > trouble-free. Often there will be no conflict, but sometimes there > will be one. One way or another, you will need to be prepared for > that if you start preserving your patches across upgrades > > > > Presenting the feature as a way to "install" would encourage people > > > who are not really thinking of testing, debugging or developping the > > > package, and motivated only by a vague wish for "the latest thing." > > > I agree that people might think of this idea, but then again what is the > > issue if they do? > > They are likely to get different behavior, and more bugs. > There is a good reason for making releases: in general, that makes > things more reliable for users. That applies to packages as well > as to Emacs overall. Running the development sources of anything > carries greater risks. Some users want to take those risks, but > it would be a mistake to urge all users to do that. I agree in principle, but with two caveats. Consider that most people use package archives like MELPA, that distribute the most recent commit by default, so this is not unfamiliar to many users. The second point is that due to the usage of version control, the user is able to revert to a previous commit or even use their own branch where they pick and choose the commits they are not interested in. > > I proposed a library along those lines last year that would automate > > this (it was called "site-lisp.el" in case you want to look the > > discussion up). It automatically byte-compiles, prepares autoloads and > > adds the directory to the load path for all files/directories in > > ~/.config/emacs/site-lisp. > > This leads me to ask two questions: > > Would my proposed package-vc-dev command, plus this, add up to the > currently proposed package-vc-install command? I did not quite understand the point of `package-vc-dev', so I cannot comment on it. What I can say that `package-vc-install' "minus" "site-lisp" would be a function that would just use package metadata to clone repositories into a specific directory. > Would this be just what the user wants > for preserving patches in packages installed from the release? Again, I am not sure. > By the way, GNU ELPA and NonGNU ELPA both have a repo which > holds the current released version of each package. Imagine > a package-vc-release command that does a checkout of the > released package from ELPA, in the same way. That would help > people add patches to the released version, and would merge > changes when a new version is released.