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.bugs Subject: bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot Date: Fri, 21 Apr 2023 13:19:39 +0300 Message-ID: <8a9d0e2b-6ae2-bcdc-efd0-52a44ac862bb@gutov.dev> References: <87a5zj2vfo.fsf@gmail.com> <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> <83pm7y6fdo.fsf@gnu.org> <47140c27-ba63-ca7b-8b9e-cc38a6f9a866@gutov.dev> <838rem636a.fsf@gnu.org> <83leil4u63.fsf@gnu.org> 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="26556"; 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: jporterbugs@gmail.com, philipk@posteo.net, 62720@debbugs.gnu.org, joaotavora@gmail.com, larsi@gnus.org, monnier@iro.umontreal.ca To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Apr 21 12:20:14 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1ppnsD-0006hw-6i for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 21 Apr 2023 12:20:14 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ppns3-0000gP-JW; Fri, 21 Apr 2023 06:20:03 -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 1ppns2-0000gC-M8 for bug-gnu-emacs@gnu.org; Fri, 21 Apr 2023 06:20:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ppns2-00030a-Db for bug-gnu-emacs@gnu.org; Fri, 21 Apr 2023 06:20:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ppns2-0004FM-5F for bug-gnu-emacs@gnu.org; Fri, 21 Apr 2023 06:20:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 21 Apr 2023 10:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62720 X-GNU-PR-Package: emacs Original-Received: via spool by 62720-submit@debbugs.gnu.org id=B62720.168207239316305 (code B ref 62720); Fri, 21 Apr 2023 10:20:02 +0000 Original-Received: (at 62720) by debbugs.gnu.org; 21 Apr 2023 10:19:53 +0000 Original-Received: from localhost ([127.0.0.1]:39423 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ppnrs-0004Eu-G0 for submit@debbugs.gnu.org; Fri, 21 Apr 2023 06:19:53 -0400 Original-Received: from new2-smtp.messagingengine.com ([66.111.4.224]:40601) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ppnrq-0004Ef-CC for 62720@debbugs.gnu.org; Fri, 21 Apr 2023 06:19:51 -0400 Original-Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailnew.nyi.internal (Postfix) with ESMTP id C3D265824C5; Fri, 21 Apr 2023 06:19:44 -0400 (EDT) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Fri, 21 Apr 2023 06:19:44 -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= 1682072384; x=1682075984; bh=W1c4+UKUbcd3A6NdknmvAjqJg4ixVK56Bpv Wv+sN6lA=; b=QVseYItl0ffi6KZDdZ4grYxhvCItID3+TnmJX7DwQUqWVNv5Asj kmqWVwxi1UlXh3OIcJoxGu25HS+tQQRd0EJ+OjEXfERLvbU0X/i7QxEiCBYrbW8Q aL+hCOvfhpmaMK4ZllkT/OxkTT0htK2VqZzMfeZC3e2V+S0gXgl5BwfgH2AE6Eb/ kgDh2fFcmm2U7QcFwUz7gF7hQscaeu3G/wE+O/MSl/Yn9psl6lwdF+JgTjj1gWuQ umSgCvWYPRwGA86iYmOxZW/9j02cMwMJAtdIoxW6x+nehU7r100fXkl0EBihB0V/ sOaPzPseFF0aLX5/LdKtLLZh4RJbTbkRfPA== 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= 1682072384; x=1682075984; bh=W1c4+UKUbcd3A6NdknmvAjqJg4ixVK56Bpv Wv+sN6lA=; b=eLoz3Xy3NyADA13HUHis3uWxBkUU1JvP71QFN7ULJtOl2W250HK 45cvSQBExy61kYkMJ2gr1a07CweI8vDS2ve4FaXUuKSIpxUzwRdewd6OfGq0loMb eyNSLoxoXsMCcMnZnahUOwukN4uoSGNU6r/FNRWqgu07wBJpyCCH9H0EkvICFLjx ykv+GWv80lFeIxTVGZYLb9Nq6ZKLb6f+K5KB4rlQrHlKdQjjH/v1UBJ/VraVzdSz oWF89MljjU9egom1fMNFPJqivM0DaO6T3x9PxHF9eMzZKz8zo7fZfeinLMTWh3K0 pTD+QuFd4ZC3dqaKoHeyC6urUbwzVBvdNpg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfedtgedgvdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepvdetffektdfftdelledtgedtuddufffhvdeilefgfedujefhheeiueeugfeh geeunecuffhomhgrihhnpehgnhhurdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 21 Apr 2023 06:19:42 -0400 (EDT) Content-Language: en-US In-Reply-To: <83leil4u63.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:260373 Archived-At: On 21/04/2023 09:37, Eli Zaretskii wrote: >> Why list the commands people use to install packages if we're talking >> about upgrading them? > > I said "to install and upgrade", not just "install". I listed the upgrade commands. > And I do think we should also consider commands that install packages > because they are part of this issue, and in particular, should be > consistent with the upgrade commands. Also, package-install was the > original cause of this thread. Okay, we also have package-menu-mark-install and package-menu-execute. >> Hopefully we'll decide that 'package-install' >> won't upgrade packages because it hasn't done that in the past. > > But it does upgrade non-built-in packages, doesn't it? Apparently not. I didn't remember whether it does, and I deduced that it does just from reading this discussion previously, but it does not. E.g. just now pressing 'U' after 'M-x list-packages' showed me that I have available upgrades for a lot of packages. But still if I evaluate (package-install 'sml-mode) where sml-mode is one of said packages, I just get the message: ‘sml-mode’ is already installed > And at least > João (and I think others as well) expected it to upgrade Eglot even > though it is now built in. I think he wants that because this way (package-install 'eglot) and (use-package eglot :ensure t) could match the behavior of Emacs 28 with an empty init directory. Backward compatibility and all that. But I think that's questionable, semantically. Given that Eglot is already "installed". Though, of course, one could argue that a bundled package is not exactly installed, but then we should change what 'package-installed-p' does as well. And think hard before doing that. >> The others would be package-update and package-update-all (can we please >> do the rename now? I know they've been in for a year, but just as this >> very discussion has shown, most people weren't even aware of their >> existence). > > If the list you provided covers all of the relevant commands and > functions, fine. Still, for completeness' sake, we should have the > higher-level description as well, as a framework against which to > examine the proposed solutions. And I'm still not convinced that we > covered all the relevant package-menu commands. It might be easier if you just ask additional question during review. >>>> - package-upgrade (nee package-update) doesn't upgrade builtin packages >>>> that never been upgraded before. It's a bug. Hopefully not too hard to fix. >>> >>> I'm okay with adding the same prefix argument to package-upgrade, >>> which would then allow upgrading a built-in package. IOW, a change >>> similar to what we did in package-install -- provided that the change >>> is safe enough to go into Emacs 29. >> >> If we agree it's a bug, why don't we just fix it? > > Precisely because, as with package-install, this is a bug for some and > a feature for others, depending on whether people do or don't want the > built-in packages to be upgraded by default. I'm having a hard time imagining someone evaluating (package-upgrade 'eglot) without intention to upgrade it to the latest version. Or invoking it interactively with same argument, expecting a different result. I don't think anyone will put it straight this way into their init script either. >> 'package-update' is an >> interactive function which itself it called from only one place: >> 'package-update-all', and since the plan is to improve both, we can make >> sure they only do what we ask of them: package-update will upgrade >> builtins when invoked directly, and package-update-all will upgrade them >> only when the builtin has been upgraded before (making it not a builtin >> anymore), or a new user option is set. > > This is one possibility, and it might make sense to some users. But I > don't think we can be sure it will make sense to an overwhelming > majority of the users. Hence the user option? But okay, this particular addition, though trivial, we could probably postpone until Emacs 30, or even avoid adding at all. It is indeed not obvious that people will really need it, although (setq package-upgradable-builtins '(eglot use-package)) (package-upgrade-all) ;; or M-x package-upgrade-all ;; or 'U' in the list-packages menu seems like a plausible scenario for a certain kind of user. Because package-upgrade does not have a menu entry, or a button anywhere, whereas package-upgradable-builtins can be altered from the Customize UI. >>>> - The current fix (commit 580d8278c5f48) is not comprehensive WRT to >>>> Joao's scenario because use-package-ensure-elpa short-circuits when it >>>> find that the package is installed ('package-installed-p' returns t). So >>>> (use-package eglot :ensure t) does not upgrade Eglot even when >>>> package-install-upgrade-built-in is t. >>> >>> I don't think (use-package eglot :ensure t) should automatically >>> upgrade built-in packages. >> >> I don't think it should, either. >> >> But IIUC that's the scenario 580d8278c5f48 was supposed to make possible. > > No, it was supposed to allow the user to invoke package-install in a > way that upgrades built-in packages, something that doesn't happen by > default. IOW, it was a partial solution to the original problem which > started this discussion, see > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62720#5 Fair enough. >>> We could make it do that if >>> package-install-upgrade-built-in is non-nil -- again, if such a change >>> could be safe enough. If not, then the same workaround as for >>> package-upgrade would do here, I suppose? >> >> What workaround would that be? use-package is not invoked interactively >> -- there is no prefix argument to pass. > > The workaround is to manually install the package from ELPA, once, > using "C-u M-x package-install RET". That's not the use-package workflow. >>>> Whereas I think we originally only wanted that for Eglot and maybe >>>> for use-package. >>> >>> "We" never did want that. João did, for obvious reasons, but that was >>> never my intent. The issue is indeed more general: what should >>> package-install and package.el in general do with built-in packages >>> for which a newer version is on ELPA? >> >> It could continue doing what it's done before: when a package is already >> installed, abort. For upgrading, we should recommend commands with >> "upgrade" in their names. > > If people agree with that, I don't think I'll object. But this is in > a sense a breaking change: package-install will only install, and > thereafter users will need to use package-upgrade. Some might dislike > such behavior changes. And we will need to make sure that all the > available methods of "installing" do not "upgrade", for consistency. Yeah, apparently it won't be a breaking change, or a change at all. >>>> For this and other minor reasons I would suggest reverting >>>> 580d8278c5f48. >>> >>> Not going to happen, not unless someone comes up with a better >>> solution that is much better and still safe enough. Personally, I >>> don't believe such a solution exists, since we don't really know the >>> answer to the above question. >> >> Could you specify which problem it's currently solving? Some particular >> scenario. > > The scenario which started this bug report, see the message whose URL > I mentioned above. IOW, we now allow users to explicitly request that > package-install includes built-in packages in the list of candidates, > and will therefore allow to upgrade them. After we fix 'package-upgrade', users will be able to 'M-x package-upgrade RET eglot RET'.