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 03:50:52 +0300 Message-ID: References: <87a5zj2vfo.fsf@gmail.com> <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> <83pm7y6fdo.fsf@gnu.org> <47140c27-ba63-ca7b-8b9e-cc38a6f9a866@gutov.dev> <838rem636a.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="39348"; 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 02:52:29 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 1ppf0l-0009xE-9N for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 21 Apr 2023 02:52:28 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ppf0N-00049h-Fa; Thu, 20 Apr 2023 20:52: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 1ppf0M-00049Y-Dz for bug-gnu-emacs@gnu.org; Thu, 20 Apr 2023 20:52: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 1ppf0L-0003SE-Tj for bug-gnu-emacs@gnu.org; Thu, 20 Apr 2023 20:52:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ppf0L-0004nl-IH for bug-gnu-emacs@gnu.org; Thu, 20 Apr 2023 20:52:01 -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 00:52:01 +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.168203827018230 (code B ref 62720); Fri, 21 Apr 2023 00:52:01 +0000 Original-Received: (at 62720) by debbugs.gnu.org; 21 Apr 2023 00:51:10 +0000 Original-Received: from localhost ([127.0.0.1]:38943 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ppezU-0004jt-Vx for submit@debbugs.gnu.org; Thu, 20 Apr 2023 20:51:09 -0400 Original-Received: from new4-smtp.messagingengine.com ([66.111.4.230]:39053) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ppezP-0004iS-O2 for 62720@debbugs.gnu.org; Thu, 20 Apr 2023 20:51:07 -0400 Original-Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailnew.nyi.internal (Postfix) with ESMTP id 6B483582085; Thu, 20 Apr 2023 20:50:58 -0400 (EDT) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Thu, 20 Apr 2023 20:50:58 -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= 1682038258; x=1682041858; bh=9mH2hZb6Ol6iT3SYhT1aw6ioFTsYrAOwznX wMIgX3Q4=; b=W4ilz507tcvYR8MIxEqgiiPiua+vntLVZWp4sU0Iuj4nijNRLuQ BJA12L+hAQEbfQxedgHPwoHuH29vwWcC5S4BDE37vmniu9T2RZ+WRhJAO6mCgH1f fiRpyDg0m29mc/GLCwz6XmusW+EVe0nI3U7tSjCoX79ui2LxsNhbq83rLGTuruWq uBIhBcj3oiXj4WEClwRoA8w4HUCBUL1I1WgyDn534OjcP2UdYUw2An1YiSP0NWkN 8D9WtFUvngKqmeMWYka6b/baRz7+VA9WKijqNglDZD2g5mhYvS4pgI8qU3FkW2At cNQMFJaC+92a7TvsfvuQEhyFhDxirdQdLcw== 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= 1682038258; x=1682041858; bh=9mH2hZb6Ol6iT3SYhT1aw6ioFTsYrAOwznX wMIgX3Q4=; b=dukduaTtPiMf5+ehAg8YNA+5hyhosFT6wohWRWYM+XPaNRJrUea Z22szu+OPiv2lOS/mf0Eg8XcX+zyOrE9RPZf2f1eu+/C6ir7YBzpBMsGRfqfFWZ8 CwKV5BnJnJqX6SOjNQizRjDEaXedwOl9eVHHlpiYZVToa52KFyrx1YmFSXpI3fKw McjhxN/8PW0uLKW8Gnp/Dhl5PgSB7gB2C85Pjlz0PeX8kRUa6a35QJm5MYhpDRbs +gD1qyVl9N57RqFHZ1YYRkom/ESVPxkQDHW8ZV+tC0yDIwTDk6EIYa7UMKUZ10Xp M/t0AyYwxx4yoHOm8tyqp1MpNiuTNK2c9zg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfedtfedggedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhephfffheeljeffgeffueeghfekkedtfffgheejvdegjeettdduheeufffggfef jeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 20 Apr 2023 20:50:54 -0400 (EDT) Content-Language: en-US In-Reply-To: <838rem636a.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:260365 Archived-At: On 20/04/2023 17:25, Eli Zaretskii wrote: > What I miss in this description is something a bit higher-level: the > list of all the ways/commands/methods people use to install and > upgrade the packages. We must have this list before our eyes to make > sure we review all the behaviors related to these activities, if we > want them all to eventually behave consistently. Why list the commands people use to install packages if we're talking about upgrading them? Hopefully we'll decide that 'package-install' won't upgrade packages because it hasn't done that in the past. Or if it's still going to do that because we don't want to revert commits, we'll just avoid touching that. > E.g., you don't mention any commands invoked from the package menu. The command which people use to upgrade packages from the package menu is called package-menu-mark-upgrades (bound to 'U'), mentioned here a few times. I also said that I hope it's *the* main way people use to upgrade packages. 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). >> - 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? '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. > But note that AFAIU there's a relatively easy workaround for this: > install the later version of the package manually, just once. It's indeed a workaround that exists, and if we were satisfied with it, we would have closed this bug as "wontfix". But it's not a very friendly way to do that (the user must hunt for the appropriate version in the packages menu), and it's very poorly scriptable (you won't be able to provide an easy and readable snippet for the user to evaluate or put in their init script). >> - package-menu-mark-upgrades and package-update-all don't upgrade them >> either. That's not necessarily a bug, but a problem nevertheless. A new >> user option could help. > > A very relevant question is: can this wait till Emacs 30? If you ask my opinion, then I already wrote it. The only thing that looks potentially complex is fixing the pinning of packages to archives. The rest should be fairly trivial. Should we leave bugfixing and easy upgrading of builtin packages to Emacs 30? I suppose we could. Let me know if it's your foregone conclusion, then I'll just walk away now. This issue doesn't solve any problems for me personally, to be clear. >> - 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. > 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. >> - package-install-upgrade-built-in is not nuanced: if we suggest the >> users to set it to t, that can result in making _all_ builtin packages >> upgradable with 'package-install'. > > It should be set to t only by users who indeed want all built-in > packages to be updated. That's why the default is nil. Sounds unnecessarily dangerous. >> 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. > We don't yet know the answer to > that, and no hope of obtaining one before Emacs 29.1 is released > (barring any calamities). I'm not sure how we're going to get the answer to that question after 29.1 is released, too. Similar to that thing with treesit modes and auto-mode-alist. >> 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. Then I could confidently propose an alternative (or not). >> But I suppose we could also try to make it more granular (e.g. turn >> the boolean option into a list). I'm not sure it's a good direction >> overall, however. > > I don't think we should go in this direction, precisely because we > don't know it's a good one. If we made it more granular, its use could become a reasonable option, then we'd be able to get some feedback from people who end up using it. I don't know what kind of people that will be, though. >> - According to Jim P., package pinning doesn't work for builtin packages >> either. Which could be a decent solution as well, e.g. putting something >> like this in the docs: (use-package eglot :ensure t :pin gnu) if the >> users want the Eglot version from ELPA -- and this form might even be >> compatible with Emacs 28. I'm not sure how difficult it would be to fix >> package pinning, however. > > As long as this is optional behavior (and AFAIU it is), I won't > object, but again, provided that the addition of this will not touch > any other code in unsafe ways. Yes, the use of pinning is and will remain optional. I'm not sure what code it will touch and how much, however. There is not a single function called "pin that" which needs to be fixed, the fix(es) will be somewhere on the common path(s) of package installation and upgrades, I think. >> The reasons for me to be hopeful are: >> >> - The functions are propose to fix are "leaves": those that are supposed >> to be used interactively, without (many) known callers in-tree. E.g. >> fixing package-update-all shouldn't affect some other part of Emacs as >> much as changing package-install could. > > Experience until now in this thread indicates otherwise: almost every > suggested change touched low-level code with many callers. It isn't > an accident that arriving at what was finally installed took so many > iterations for such a simple change. You might be correct at that, but note that I'm suggesting a slightly different set of goals than what had been discussed here before. So the changes will likewise need to be different.