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: Sat, 22 Apr 2023 13:48:41 +0300 Message-ID: References: <87a5zj2vfo.fsf@gmail.com> <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> <8a9d0e2b-6ae2-bcdc-efd0-52a44ac862bb@gutov.dev> <83h6t94hru.fsf@gnu.org> <7676c8d2-1324-31e7-38b3-de167ecf683a@gutov.dev> <835y9o2uh2.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="15798"; 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 Sat Apr 22 12:49: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 1pqAo4-0003sg-SR for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 22 Apr 2023 12:49:29 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pqAnh-0007jD-Db; Sat, 22 Apr 2023 06:49:05 -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 1pqAne-0007ig-My for bug-gnu-emacs@gnu.org; Sat, 22 Apr 2023 06:49: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 1pqAne-0002dH-Eg for bug-gnu-emacs@gnu.org; Sat, 22 Apr 2023 06:49:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pqAne-0003t1-2A for bug-gnu-emacs@gnu.org; Sat, 22 Apr 2023 06:49: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: Sat, 22 Apr 2023 10:49: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.168216053314918 (code B ref 62720); Sat, 22 Apr 2023 10:49:02 +0000 Original-Received: (at 62720) by debbugs.gnu.org; 22 Apr 2023 10:48:53 +0000 Original-Received: from localhost ([127.0.0.1]:41926 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pqAnV-0003sX-45 for submit@debbugs.gnu.org; Sat, 22 Apr 2023 06:48:53 -0400 Original-Received: from new2-smtp.messagingengine.com ([66.111.4.224]:59163) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pqAnS-0003sH-NV for 62720@debbugs.gnu.org; Sat, 22 Apr 2023 06:48:51 -0400 Original-Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailnew.nyi.internal (Postfix) with ESMTP id 7BB405821CA; Sat, 22 Apr 2023 06:48:45 -0400 (EDT) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Sat, 22 Apr 2023 06:48:45 -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= 1682160525; x=1682164125; bh=ivkJ2nJqOM98vCIfQTtjSjFwQUPI4SPWIt8 LoIqH9dM=; b=ESwqHrdxa4mODAX0pi1EmpMhkjQpTy3tQCiLyDiuAWn3SA7xYoz BQWYhzgjVvHGWl5CTzEHf90/A5o0LcDiry0SfpMy2O6vkCvHMnFNplAumS1lfCfo 32vcETRToxQ0Hpl3YQlROG8wiJxGE3eKT4v3Riu5Oyds+8VeGMWUMffcAd30KtxJ ntJBOXvPXCwcKTuCqXgGZLfkBv/D0I08exq5pQ094Xy53P6V4vPHvxS+vXB4Tq7+ Yq7A0RXReFl9HjbS6Rxru3zmopK3N7rB2T9bRtstEHdFbo3GaeiDLUlSJTiofpM9 Vhjy09spgB6EZLG62AOBeo1YFpgm4rzUU7w== 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= 1682160525; x=1682164125; bh=ivkJ2nJqOM98vCIfQTtjSjFwQUPI4SPWIt8 LoIqH9dM=; b=LNGD2KLsx/DVUIQvo9BPXn1Xm9zeOGR+wVsQ/7OOpIcDdSgnA4K kDA5e0S9DPNcoAy/0qHl1M44auB5QdiiKdJwV33/ZnPis64xXTg/wtRB+UtfnjHJ +3KaaqgsFgfw7QI+n0qvao7bMbPadbNCamWxZj+Z6YUM9BOPWZmfkGJz3ZaPNhbr XmrSh3PfwkYktPZ+71NPJvIDmstfzvvrSUrLKDS7nHih4adEEbqCpdMAuweYIbBz fms12PDLhIitck1FAh3t8wZYTn0pXuCyPk57yEG1VFQdTRMGGaPnqMog8SGei0Sa zudeat3GE06KJC9f5l+1gacSB06MJu6NZwg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfedtiedgfedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepvdekuedutdefffegkeevfeevgfevffejffdvieekgfeggfeghfduteehkefg leehnecuffhomhgrihhnpeigkhgtugdrtghomhenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpegumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 22 Apr 2023 06:48:43 -0400 (EDT) Content-Language: en-US In-Reply-To: <835y9o2uh2.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:260456 Archived-At: On 22/04/2023 11:26, Eli Zaretskii wrote: >> The above scenarios (package-install or (use-package eglot :ensure t)) >> when ~/.emacs.d/elpa is empty, result in the very latest Eglot being >> installed when using Emacs 28. And will result in something different >> with Emacs 29 (not the latest version). That's not nothing: the CI >> scripts will have to be updated, and the user instructions for reporting >> problems will have to be made more complicated as well. Some >> possibilities will simply be gone (the user won't be able to upgrade >> Eglot to the very latest by deleting it from ~/.emacs.d/elpa and calling >> package-install, for example). This *is* a non-backward compatible >> change from the perspective of Eglot's maintainer. > > We were talking about users installing and updating packages. The CI > scenario doesn't belong here. It is also much less important one > (test suites are always required to chase the changes in development). > > Let's not complicate an already complicated set of issues by bringing > up unimportant secondary use cases. You asked. I relayed what's already been said on the matter by Joao. >> I, personally, don't really buy this kind of argument, but I figured you >> might. After all, it's rather in line with reasoning we've seen voiced >> around these parts many times ("X has worked this way for Y years, let's >> never change it from now on"). Classic https://xkcd.com/1172/. > > If you allude to my reasoning, then it is never that simplistic, and > always considers each case separately, not "by analogy". Of course that's a simplification. Hence the "might" anyway. >> Either way would be fine, IMO, as long as the behavior is logical and >> matches documentation. But having a separate command to upgrade now lets >> us fix it separately without worry of breaking something more globally. > > Except that, based on what we have (see below) ,we don't really have > an "upgrade" operation, we only have "install" and "delete" > (i.e. "uninstall"). So maybe we should preserve that, to minimize > problems and user surprise/confusion. We do. We have commands for upgrading, both in "list-packages", and used interactively. Which do the thing of installing the new version and removing the old one. Which is what upgrading means in various tools, e.g. 'apt'. >>> In interactive invocation, package-upgrade calls completing-read with >>> its 4th argument non-nil, so you cannot select a package which is not >>> in the collection returned by package--updateable-packages. What I >>> meant above is to allow that collection to include built-in packages >>> as optional behavior. I just tried invoking package-update for ElDoc, >>> and I get "No match" after typing "eldoc" to its prompt, although >>> eldoc version 1.14.0 is in the list presented by list-packages as >>> "available". >> >> That's what I imagined: adding a new optional argument to >> package--updateable-packages which would include builtins in the result. >> >> And only pass it when called from package-upgrade. >> >> Hopefully that's the kind of optional that you meant. > > Yes, something like that. Presumably activated by the same new option > introduced for package-installed. Okay, then it's something different, and you didn't answer my question. >>>>>> '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? >>> >>> Which one? Are you suggesting to add a new one? If so, why not use >>> the one we already added, package-install-upgrade-built-in? >> >> The user option I was thinking of would probably be called a little >> shorter: package-upgrade-built-in. And it would only affect the upgrader >> commands. > > We could rename the existing option, if the name is the problem. > Otherwise, I don't see why we would need two separate options: they do > the same job and have the same meaning from the user's POV. The name is a problem, yes. What could also be a problem is a user that customizes this option to have package-update update builtin packages (a reasonable behavior that should be on by default anyway), will also automatically have change the behavior of package-install to be more surprising (install an already installed package). Further, if we have a user option affect package-update, we'll have to alter package-update-all and package-manu-mark-for-update in the same patch (otherwise we'll have more nonsense on our hands). Whereas the first version I sent is more minimal. >> All this is to say, the first step (upgrading Eglot to the version from >> ELPA) will be less user-friendly compared to the other UIs we have. But >> it's probably manageable, especially if documented well. > > I don't see why it would be less user-friendly. The same reason we do have commands with "upgrade" in their names, rather than force everybody to use the "install" and "delete" ones. >> My point here, however, is that commit 580d8278c5f48 improved the >> situation to a lesser degree that some people here might have expected. > > One again: commit 580d8278c5f48 solved precisely the problem which > opened this bug report, nothing more, nothing less. It doesn't seem like the originator of the report agrees with that. >> But we can conclude that we do have two different installation actions: >> >> - package-install which will install the latest version of a package, >> but only if it's not installed; >> - package-menu-mark-install, which will mark a specific version for >> installation, disregarding whether some earlier version is already >> installed; the previous version will remain installed still. > > Which is again a breaking behavior change, AFAIU. Is this a good idea > so late in the development of Emacs 29? The above is not a breaking change, it's how things work already. And have been working for quite a while. >> But even if we decide that we want to eliminate that split, doing *that* >> would really be a breaking change. I don't have a reasonable plan to >> present for doing that in Emacs 29, so far. > > There's no "split". What I wanted to point out is that we don't seem > to have a clear vision of these two commands, since they are confusing > intertwined. In fact, one could argue that package-upgrade in its > current form is simply a convenience shortcut for "delete old and > install new". What should an upgrade command do, in your opinion, if not "delete old and install new"?