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, 25 Oct 2022 16:13:53 -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> 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="36315"; 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@gnu.org Tue Oct 25 22:14:54 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 1onQK5-0009DJ-Ed for ged-emacs-devel@m.gmane-mx.org; Tue, 25 Oct 2022 22:14:53 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1onQJA-00022V-DZ; Tue, 25 Oct 2022 16:13:56 -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 1onQJ8-0001vK-3N for emacs-devel@gnu.org; Tue, 25 Oct 2022 16:13:54 -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 1onQJ7-0002sN-Pd; Tue, 25 Oct 2022 16:13:53 -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=5Ep+F4dlOI8ixUxJ5iq4S43Ivn/MHjxwODEX8D8j4aY=; b=hW+y+JJPm3dL BUvKGZxxxI7WAoUiyLlu6gZ4E2aO5qdnp/YD5kwls2dxVKcuw2R/V9hkVaEvNqiL50uaLZcHR7QLj adrk7bnNql5UcPUUdsirWXmq0Tu/lbcMQfKIbmfbJBB7yj9m6IPvDjTOfBLdTWx7vfkJEBSVAQe1d ADNoNZOTXwgainu3k6tSPLzYvccPVY5w2XNk2A75Hak2V3MCMoiH5DM3EhQkaud3/f8Aip5yUZ6cY zHnCNcPcM6wwt39Eu31QN6dyYfD3TdhpbKOvavbVRVYp1ccZemfPA8XWvoFGNz+ChfsHPCnP5koJW GIJvi3w+XHOOu5oc1vIt6Q==; Original-Received: from rms by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1onQJ7-0008Bp-H2; Tue, 25 Oct 2022 16:13:53 -0400 In-Reply-To: <878rl6syg8.fsf@posteo.net> (message from Philip Kaludercic on Sun, 23 Oct 2022 09:04:23 +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@gnu.org Xref: news.gmane.io gmane.emacs.devel:298494 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. ]]] > > 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? 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? 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. 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. I think `package-dev-repo' would be the command now called `package-vc-install'. -- 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)