From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: emacs-29 9b775ddc057 1/2: ; * etc/EGLOT-NEWS: Fix wording of last change. Date: Sat, 6 May 2023 22:14:13 +0300 Message-ID: <667d5cc1-4a3c-5cd4-21c0-adff89cea769@gutov.dev> References: <168335548287.8529.4912240840977468283@vcs2.savannah.gnu.org> <20230506064443.56C75C22F15@vcs2.savannah.gnu.org> <59835735-faa0-4096-e491-35ec92964b7a@gutov.dev> <831qjthhm8.fsf@gnu.org> <715cdac6-83f6-6907-2ff8-3b33381f3487@gutov.dev> <83zg6hg29c.fsf@gnu.org> <83ttwpfvcr.fsf@gnu.org> <83h6spfose.fsf@gnu.org> <35df1362-fd92-9424-97d0-df3479414677@gutov.dev> <83edntfm6e.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3799"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Cc: emacs-devel@gnu.org To: Eli Zaretskii , Philip Kaludercic , Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat May 06 21:14:48 2023 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 1pvNMj-0000ly-SI for ged-emacs-devel@m.gmane-mx.org; Sat, 06 May 2023 21:14:47 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pvNMM-0006Gy-DJ; Sat, 06 May 2023 15:14:22 -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 1pvNMK-0006F3-ST for emacs-devel@gnu.org; Sat, 06 May 2023 15:14:20 -0400 Original-Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pvNMH-0008QS-Kv; Sat, 06 May 2023 15:14:20 -0400 Original-Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 94E3E5C0222; Sat, 6 May 2023 15:14:16 -0400 (EDT) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Sat, 06 May 2023 15:14:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1683400456; x=1683486856; bh=MEwHHH8Ms4cfjx35AqcyF8frKMLkjK5Qjsv bnKDYGJ8=; b=okheQPbDz43M/cvY5u1meE5HfnBxRDeV2TwexpdyRpQjLnoVO89 hn+UCyW2FkJgLCH/ZZ7sOBzx5vcv5wyACEkIUyX9FYsvXDTXK17FbA5DHc57J6tR hKQr+AnGWhMqa7sK+ox9N7E9eGd61S6SGTbnMrlIlGgrg7p13Wz8Sd5Trn2KTHtD 7GTzMOzLEbqPSguyhU3mFhPwoDopfwIuw1NP5bqZXBSmQ/X8zKJC3mOQXHh38k4M ICzOShfxj4Z4DnMxUJ3pRdaqePF0Tng0Dp/b5hGWf4ssIYZ55YkOrocSB1lZT957 A4jqY7Pv33VMoeOGL9Vf9DY/bZJMbpzAeIQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1683400456; x=1683486856; bh=MEwHHH8Ms4cfjx35AqcyF8frKMLkjK5Qjsv bnKDYGJ8=; b=XsZ19VHCpwPTtFExuk5OhuYB7MGt9T9BKisn/gsJlJJ43jTP2DI 8VsKxNhkrKPPIK0cGhNzkUvlLVM/fDEEbeTygCJqb7Z0iYT8sAp4SeK4ECh30gu4 +ZKBtCKT+MvCXR4ErsWf9x3IeaWhaMzTf8ARw4gcb7zZmIurPR1INzmuqC3qReGr X4JNqKTJJ9GwLkRLwKzhbhaIYESuCWd7POL2pt9R3kb1wq3zvR5axFWHaHXE5jDJ rcvl3W+luOlyCySNDmd864T3Q0ZFK3sPtE7TlSHVzY4og61t0qBqH7mwBnP65Kbz 1kIpAhq8Qp9rp1SNzO3YZssEuOOwmW51jJA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfeefgedguddufecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttdefjeenucfhrhhomhepffhm ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg htthgvrhhnpeekjeegleegvdefleehgeefieffhefhtdeitdffheekfefftdfgieeuieeg tedtfeenucffohhmrghinheprhgvugguihhtrdgtohhmnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 6 May 2023 15:14:15 -0400 (EDT) Content-Language: en-US In-Reply-To: <83edntfm6e.fsf@gnu.org> Received-SPF: pass client-ip=66.111.4.25; envelope-from=dmitry@gutov.dev; helo=out1-smtp.messagingengine.com X-Spam_score_int: -70 X-Spam_score: -7.1 X-Spam_bar: ------- X-Spam_report: (-7.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, NICE_REPLY_A=-4.28, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:305930 Archived-At: On 06/05/2023 19:40, Eli Zaretskii wrote: >> Date: Sat, 6 May 2023 18:54:47 +0300 >> Cc: joaotavora@gmail.com, emacs-devel@gnu.org >> From: Dmitry Gutov >> >>>> If some version of it is installed from ELPA (!) already, 'M-x >>>> package-install' won't upgrade. >>> >>> Then I don't understand why you decided to drop the similar change to >>> package-upgrade. At the time I thought package-install can be used as >>> an alternative, but if it cannot, I think we should add to >>> package-upgrade the same optional behavior of upgrading a built-in >>> package as we have in package-install. >> >> We now have a better solution on master: 'M-x package-upgrade' simply >> upgrades the built-ins, no questions asked. > > What we have on master is not relevant to what we discuss here, which > is Emacs 29. What's on master is how I think this function should look and work. Any potential change in Emacs 29 should be compatible with it. >> If we added the behavior similar to the addition in package-install >> (with prefix arguments and guarded by an option, possibly even a new >> optional argument), we'd have to carry over that awkward convention to >> Emacs 30 in some form. And as you recall, Joao wasn't happy with either >> solution anyway (of those that you liked enough). > > The question is: is it reasonable not to allow package-upgrade in > Emacs 29 to upgrade a built-in package? Not even as an option? We've documented that it does not upgrade built-ins. That's what we settled on. The discussion about options brings us back to complications: - That package-upgrade could (probably should) work differently from package-upgrade-all WRT built-ins - That it would probably make sense to add a new different option rather than reuse package-install-upgrade-built-in - package-upgrade-all would require a yet another option (or a separate value, at least) So we might as well skip all this, retouch the docs and call it a day. Even fixing 'M-x package-upgrade' properly won't please everyone either: e.g. the latest question on Reddit (https://www.reddit.com/r/emacs/comments/139f8r9/comment/jj3kmty/?context=3) is about package-menu-mark-upgrades including built-in Eglot as well. >>> What other methods currently exist to upgrade an already installed >>> package (or a non-built-in package that is already installed)? I know >>> about one -- via lisp-packages (a.k.a. package menu); are there >>> others? >> >> Also: >> M-x package-upgrade >> M-x package-upgrade-all >> >>> Will any of these methods upgrade a built-in package, at least as an >>> optional behavior? >> >> Not in Emacs 29. > > So I think we have a problem, and I think we need to solve it. > > Philip, Stefan: WDYT about this? > > What about installation from the list-packages menu: will it upgrade a > built-in package if package-install-upgrade-built-in is non-nil? Installation or upgrade? package-menu-mark-upgrades ('U') is not affected by package-install-upgrade-built-in. It won't. But a version from ELPA can still be installed by using 'i' in the list-packages menu. Just as we've written in the docstrings. >>> But if emptying ~/.emacs.d/elpa is not a frequent use case, why should >>> we care about it so much? It sounds like bug#62720 and the entire >>> long dispute that followed were focused on this strange use pattern, >>> instead of talking about more reasonable upgrade scenarios? >> >> We focused on it because, apparently, using 'M-x package-install' worked >> in more cases in Emacs 28 than in Emacs 29. And some think it's >> important. And because 'package-upgrade' is not in Emacs 28 at all. > > If package-upgrade was not in Emacs 28, how did users upgrade > installed packages in Emacs 28 and before? Using package-menu-mark-upgrades ('U'). The built-in packages like project or xref often didn't get upgraded at all, or if they did, that happened usually because of some other package (like Eglot) declaring dependency on some newer version of either. Then that happened together with Eglot's upgrade. >> Personally, I think it's better to focus on fixing 'package-upgrade' >> (which I did). But I don't think it's constructive to hide that fix >> behind a pref. > > I don't see a zero-sum game here. We could focus on both. But I > don't use package.el and never will, so if those who use it and > maintain it think otherwise, I won't insist. Although I find this > stance very strange indeed, to say the least. We haven't been able to settle on a reasonable change that would satisfy your safety requirements. We should probably focus on getting Emacs 29 out soon and then look into backporting 53cc61d60db to Emacs 29.2.