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: Stability of core packages (was: Not easy at all to upgrade :core packages like Eglot) Date: Thu, 20 Apr 2023 01:06:10 +0300 Message-ID: References: <87a5zj2vfo.fsf@gmail.com> <834jpifizy.fsf@gnu.org> <83y1mue1qi.fsf@gnu.org> <83sfd2e01f.fsf@gnu.org> <1a5e5837-513b-84d8-3260-cdbf42b71267@gutov.dev> <83sfcz9rf2.fsf@gnu.org> <09a49ab9-ac72-36a9-3e68-9c633710eba7@gutov.dev> <83r0sh8i1q.fsf@gnu.org> <35638c9d-e13f-fad8-5f95-ea03d65d4aa2@gmail.com> <87a5z3izst.fsf@web.de> <83v8hr7qk9.fsf@gnu.org> <83pm7z7nkc.fsf@gnu.org> <4b63ef62-5e1c-3dcf-ec7b-06b69e79133b@gutov.dev> <83o7nj7mfn.fsf@gnu.org> <556e0fbb-215e-c11d-0e8b-73e97441abbb@gutov.dev> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39409"; 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: Eli Zaretskii , arne_bab@web.de, jporterbugs@gmail.com, emacs-devel To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Apr 20 00:07:12 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 1ppFxH-000A2e-A3 for ged-emacs-devel@m.gmane-mx.org; Thu, 20 Apr 2023 00:07:12 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ppFwQ-0007br-QZ; Wed, 19 Apr 2023 18:06:18 -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 1ppFwO-0007bO-Pm for emacs-devel@gnu.org; Wed, 19 Apr 2023 18:06:16 -0400 Original-Received: from new2-smtp.messagingengine.com ([66.111.4.224]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ppFwM-00023a-EI; Wed, 19 Apr 2023 18:06:16 -0400 Original-Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.nyi.internal (Postfix) with ESMTP id 6D6FC5823B9; Wed, 19 Apr 2023 18:06:13 -0400 (EDT) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Wed, 19 Apr 2023 18:06:13 -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= 1681941973; x=1681945573; bh=YL7Ak7NqFONnXhTlqOiyA6FaYgm7b5kJmgG i61BNJjs=; b=W+kmk5+7nxe27rpLeYvyAQbjvCwmiAAdFFILF8buWmXIeH6jfry ufX7XtvSTR7j9ZJLlhheJxbMO28w8H23rbBECO8GK2PZkrgmS6hElWL/ww28aqZF pkBUXaNqolHNK2tlj3kNhBM5ksKBsDJUB+JcrCFTpEHDir76dzduaRqLjhe4MXR4 xZBIeD7mgDc2uhQ6iABLBdGyuoUwz4ZNXNtQHO8Xxnf11K1a5U1eBodoAiqvffCV imNO3A1kg2mlSiRZnl9B7lzPxVa7DJ9B4aVtR3q5ensZ9vbIf9PeuAdVd79tb4WE QyLPE7nW52aOtfcfsTRz4cbT5HDMnVwBSxQ== 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= 1681941973; x=1681945573; bh=YL7Ak7NqFONnXhTlqOiyA6FaYgm7b5kJmgG i61BNJjs=; b=HzxucGidYf1/FNRw7rA4UKX+hVxzCzvR9kxtEfrki0bK2Nv3kt1 M9/vArjGis/6+jsrAOIzcEUhOhFSDOZpm9CMEpxeGhmVO1h74ISyto0kqnTlpI/p BKPrJp8ujF9hVBrTmkrjB7ApWBfgfgNdzXjn+b2Nz8nabv/9Yrfd9GZa4f2TDesG bYD/nFBk6xqaBTSUhV47C4gSOwn22nu/XsldNQI843NdOk7ekup4ssQCJsB7zlnN MVa4EUwjObWqIQUV49MJi6ryA4ID25rA5JdterrVt3+5WoM6k7HRWbp5R3lnEHXr 0WIEkdT5anG5UfWggMZ2wOZ6RgUxZbet+Qg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfedtuddgtdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepvdetffektdfftdelledtgedtuddufffhvdeilefgfedujefhheeiueeugfeh geeunecuffhomhgrihhnpehgnhhurdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 19 Apr 2023 18:06:11 -0400 (EDT) Content-Language: en-US In-Reply-To: Received-SPF: pass client-ip=66.111.4.224; envelope-from=dmitry@gutov.dev; helo=new2-smtp.messagingengine.com X-Spam_score_int: -53 X-Spam_score: -5.4 X-Spam_bar: ----- X-Spam_report: (-5.4 / 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=-2.597, RCVD_IN_DNSWL_LOW=-0.7, 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:305468 Archived-At: On 19/04/2023 23:57, João Távora wrote: > On Wed, Apr 19, 2023 at 9:50 PM Dmitry Gutov wrote: > >> So... are you sure that (use-package 'eglot :ensure t) upgrades/upgraded >> the package? >> >> From what I'm reading in use-package-ensure-elpa, all 'package-install' >> calls are wrapped in >> >> (unless (package-installed-p package) >> ... >> >> That seems to mean that, as long as the package is installed already >> (whether by being bundled, or because of a previous manual >> installation), it shouldn't get upgraded when this form is executed. > That's true. Exactly the same as package-install. It will not > reinstall over another one. OK then, I think have to re-evaluate my position on this. Previously, I guess, I made some hasty conclusions from how the discussion went on without refreshing the exact details about package.el and use-package (the latter I never knew to begin with). Apologies. Eli, let me know if we should take this back to the bug tracker instead. > But that doesn't change anything. In Emacs 26/27/28 from scratch > package-install and use-package_will_ rev up Eglot to whatever is the > newest version. In Emacs 29 it won't. I think one of the conclusions to be made here is that even if (package-install 'eglot) now installs the newest version of Eglot in Emacs 29, (use-package 'eglot :ensure t) still won't do that in Emacs 29 because (package-installed-p 'eglot) returns t still. So the commit 580d8278c5f48 doesn't help with your "most common upgrade method" cited below, if they rely on use-package instead of calling 'package-install' directly. The patch I +1'd here https://debbugs.gnu.org/62720#467 wouldn't help with (use-package 'eglot :ensure t) either, IIUC. But it would help in case the user put (package-install 'eglot) inside their init script, or if the CI script contains that. But the CI scripts could be fixed anyway (there must be a lot fewer of them out there than there are user installations). Next: 'package-install' isn't supposed to install a new version when some version is already installed. The docstring says so, and I just tried this out: had older 'vertico' installed (with a newer one available in the repo), evaluated (package-install 'vertico), got back the message "already installed". Do we want to change the semantics of 'package-install' just so the (minor) fraction of users who call this function directly will get Eglot upgraded when starting over from an empty config with Emacs 29? And/or change (package-installed-p 'eglot) to return nil when the appropriate user option is set? I'm not sure that's wise, certainly not the latter. > In fact deleting Eglot and restarting Emacs the config run again is what > I suppose the most common upgrade method (since there is no > package-update in Emacs 28). I've never considered this particular scenario, but as explained above, it's still not "fixed" by either of the proposed approaches. Not entirely, at least. The most common upgrade method, though, is hopefully 'package-menu-mark-upgrades'. Or: M-x list-packages U x And that one also doesn't work for Eglot and other builtin packages. Unlike 'package-install', this behavior is not obviously correct, although it's "always been like this" so we're probably not going to change what it does by default at this point in time. Another function which is supposed to upgrade packages in 'M-x package-update' (why aren't people commenting on bug#62750? the naming's gonna drive me crazy). This one is obviously incorrect because upgrades exist for Eglot, and yet it doesn't suggest any. So I would suggest to focus on functions that don't work as intended. Namely: - Add a user option for the list of builtin packages which would be upgraded automatically by 'package-menu-mark-upgrades' and 'M-x package-upgrade-all' (nee package-update-all). Maybe make it nil by default, or maybe add 'eglot' to it. I don't have a strong opinion. - Fix 'M-x package-upgrade' (nee package-update) to suggest Eglot as one of the options and actually perform the upgrade. That shouldn't require changes to 'package-install' because, as we already know, the user can already install a newer version of Eglot using the 'list-packages' menu (and picking the exact version manually). That execution path is going to go through 'package-install' as well, so it must be suitable already. - Revert 580d8278c5f48 because it creates odd semantics (upgrading certain packages that are already installed but not others) and it doesn't solve the issue with (use-package 'eglot :ensure t) anyway. We could keep it, but seems like a half-measure that didn't make anyone happy anyway. OTOH, it could minimize the rewrites of CI scripts.