From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.bugs Subject: bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot Date: Thu, 13 Apr 2023 15:10:01 +0000 Message-ID: <87edonlsxi.fsf@posteo.net> References: <87a5zj2vfo.fsf@gmail.com> <83sfd5761f.fsf@gnu.org> <87zg7djrgr.fsf@gmail.com> <83o7nt73za.fsf@gnu.org> <83mt3d73c2.fsf@gnu.org> <87r0sptinq.fsf@posteo.net> <83jzyh706c.fsf@gnu.org> <875ya1tdwf.fsf@posteo.net> <83edop6sdy.fsf@gnu.org> <831qkp6o0i.fsf@gnu.org> <83wn2h5825.fsf@gnu.org> <87wn2gkhzr.fsf@posteo.net> <83cz485oxi.fsf@gnu.org> <87leiwdyff.fsf@posteo.net> <834jpk5hih.fsf@gnu.org> <871qkom3fj.fsf@posteo.net> <83mt3b4yfc.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38797"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, 62720@debbugs.gnu.org, joaotavora@gmail.com, monnier@iro.umontreal.ca To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Apr 13 17:10:19 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 1pmyaY-0009vV-FB for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 13 Apr 2023 17:10:18 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pmyaL-0001zu-Ku; Thu, 13 Apr 2023 11:10: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 1pmyaJ-0001zN-Ff for bug-gnu-emacs@gnu.org; Thu, 13 Apr 2023 11:10:03 -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 1pmyaJ-0005iA-5e for bug-gnu-emacs@gnu.org; Thu, 13 Apr 2023 11:10:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pmyaI-0006wD-1K for bug-gnu-emacs@gnu.org; Thu, 13 Apr 2023 11:10:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Philip Kaludercic Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 13 Apr 2023 15:10: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.168139858626637 (code B ref 62720); Thu, 13 Apr 2023 15:10:02 +0000 Original-Received: (at 62720) by debbugs.gnu.org; 13 Apr 2023 15:09:46 +0000 Original-Received: from localhost ([127.0.0.1]:44459 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pmya2-0006vZ-Ev for submit@debbugs.gnu.org; Thu, 13 Apr 2023 11:09:46 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]:47331) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pmyZw-0006vE-V4 for 62720@debbugs.gnu.org; Thu, 13 Apr 2023 11:09:44 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 02281240425 for <62720@debbugs.gnu.org>; Thu, 13 Apr 2023 17:09:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1681398574; bh=oz99EXs0DiQThzfRoxXQ5Ygj1DXft2+KjR/L7pqetsk=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=OE8TFhg3pj2L9iysxBiQv7mCcFJvde6Jr/5z2DYZM8fieXZeRz/0qzonQZGjMynjc 8oZvMtofUfOCM+SD/z2As8tjpVAsdGKVZul6wVzSKGRFo/lYsI94dzsda4QXQlAg0R twlxmP+vYReaTszcCVlckgZJVdYVkl0/96yWvXWehdcw8vUtWk/8rOTlp6nUsIfmjX aytNmljZ5HwocgSD6IiP/vHf2B3Sx4qDUbrdcFdP4Nau0vyQgEB81+aQUnx4ymXiL3 OSu43aBVgQ44Yf3MBpeyOWdI/5aIv+GJyG/2vkvG0a2myR3qbUCBfuCpuNFfzGmtSw oh7nlFjExy0DQ== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Py2zw2VRLz6tvl; Thu, 13 Apr 2023 17:09:32 +0200 (CEST) In-Reply-To: <83mt3b4yfc.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 13 Apr 2023 18:03:19 +0300") Autocrypt: addr=philipk@posteo.net; keydata= mDMEZBBQQhYJKwYBBAHaRw8BAQdAHJuofBrfqFh12uQu0Yi7mrl525F28eTmwUDflFNmdui0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiWBBMWCAA+FiEEDg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwMFCQHhM4AFCwkI BwIGFQoJCAsCBBYCAwECHgECF4AACgkQ8xYDWXahwulikAEA77hloUiSrXgFkUVJhlKBpLCHUjA0 mWZ9j9w5d08+jVwBAK6c4iGP7j+/PhbkxaEKa4V3MzIl7zJkcNNjHCXmvFcEuDgEZBBQQhIKKwYB BAGXVQEFAQEHQI5NLiLRjZy3OfSt1dhCmFyn+fN/QKELUYQetiaoe+MMAwEIB4h+BBgWCAAmFiEE Dg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwwFCQHhM4AACgkQ8xYDWXahwukm+wEA8cml4JpK NeAu65rg+auKrPOP6TP/4YWRCTIvuYDm0joBALw98AMz7/qMHvSCeU/hw9PL6u6R2EScxtpKnWof z4oM 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:259862 Archived-At: Eli Zaretskii writes: >> From: Philip Kaludercic >> Cc: joaotavora@gmail.com, monnier@iro.umontreal.ca, 62720@debbugs.gnu.= org, >> larsi@gnus.org >> Date: Thu, 13 Apr 2023 11:23:12 +0000 >>=20 >> > Why did the original code use symbol-name, but the new one doesn't? >>=20 >> To my knowledge, completing-read given a collection of symbols will use >> the symbol names as candidates, or is this more complicated? > > So you are saying that the symbol-name call in the original code was > simply redundant? Yes, it appears so. >> >> @@ -2221,11 +2236,16 @@ package-install >> >> (package--save-selected-packages >> >> (cons name package-selected-packages))) >> >> (if-let* ((transaction >> >> - (if (package-desc-p pkg) >> >> - (unless (package-installed-p pkg) >> >> - (package-compute-transaction (list pkg) >> >> - (package-desc-reqs= pkg))) >> >> - (package-compute-transaction () (list (list pkg))))= )) >> >> + (cond >> >> + ((package--upgradable-built-in-p pkg) >> >> + (let ((desc (cadr (assq name package-archive-conten= ts)))) >> >> + (package-compute-transaction >> >> + (list desc) (package-desc-reqs desc)))) >> >> + ((package-desc-p pkg) >> >> + (and (not (package-installed-p pkg)) >> >> + (package-compute-transaction >> >> + (list pkg) (package-desc-reqs pkg)))) >> >> + ((package-compute-transaction () (list (list pkg))))= ))) >> > >> > I think the first condition of 'cond' should be >> > >> > ((and current-prefix-arg (package--upgradable-built-in-p pkg)) >> > >> > to make sure we don't affect the non-prefix-arg invocations in any >> > way. >>=20 >> The issue here is that this breaks the non-interactive invocations like >> (package-install 'eglot), unless they invoke the function while binding >> `current-prefix-arg', which I don't think is a common practice. > > Then let's add another optional argument, and let prefix arg set it. > Would that resolve this issue? That could solve it, but a user option might be more elegant. We could set it to nil for now, and change it to non-nil for the next release. >> >> Note that (package-install 'eglot) does download code, but I believe >> >> that this is the correct approach and would align with what Jo=C3=A3o >> >> wanted. >> > >> > I'm not sure I follow: which code does the above download? >>=20 >> I did not change any of the code that downloads anything, all this does >> is prompt the user for built-in packages when invoked interactively with >> a prefix argument and if package-install is invoked with a built-in >> package, then it will switch to the ELPA version. This will not happen >> in interactive usage, since `completing-read' is called with >> REQUIRE-MATCH. > > So you are saying that non-interactive calls to package-install could > install Eglot from ELPA even without the changes, is that right? No, my proposed diff changes what package decides to download (the planning phase), but doesn't touch anything after that. The current state is that (package-install 'eglot) just prints =E2=80=98eglot=E2=80=99 is already installed