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: Wed, 12 Apr 2023 13:42:56 +0000 Message-ID: <875ya1tdwf.fsf@posteo.net> References: <87a5zj2vfo.fsf@gmail.com> <87y1mz38rl.fsf@posteo.net> <87ile2n0kn.fsf@gmail.com> <83v8i2abqi.fsf@gnu.org> <87wn2ilgx7.fsf@gmail.com> <83a5ze9uc1.fsf@gnu.org> <831qkq9rpy.fsf@gnu.org> <83pm898xb9.fsf@gnu.org> <87h6tlleg0.fsf@gmail.com> <8335558qc7.fsf@gnu.org> <83sfd5761f.fsf@gnu.org> <87zg7djrgr.fsf@gmail.com> <83o7nt73za.fsf@gnu.org> <83mt3d73c2.fsf@gnu.org> <87r0sptinq.fsf@posteo.net> <83jzyh706c.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20392"; 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 Wed Apr 12 15:43: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 1pmakp-00059D-1e for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 12 Apr 2023 15:43:19 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pmakb-00067I-8V; Wed, 12 Apr 2023 09:43: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 1pmakZ-00066l-BZ for bug-gnu-emacs@gnu.org; Wed, 12 Apr 2023 09:43: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 1pmakZ-0005c6-3X for bug-gnu-emacs@gnu.org; Wed, 12 Apr 2023 09:43:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pmakY-00013Z-Gh for bug-gnu-emacs@gnu.org; Wed, 12 Apr 2023 09:43: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: Wed, 12 Apr 2023 13:43: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.16813069574026 (code B ref 62720); Wed, 12 Apr 2023 13:43:02 +0000 Original-Received: (at 62720) by debbugs.gnu.org; 12 Apr 2023 13:42:37 +0000 Original-Received: from localhost ([127.0.0.1]:39385 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pmak8-00012q-CG for submit@debbugs.gnu.org; Wed, 12 Apr 2023 09:42:36 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]:37785) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pmak5-00012Y-DM for 62720@debbugs.gnu.org; Wed, 12 Apr 2023 09:42:34 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 7F2AB240105 for <62720@debbugs.gnu.org>; Wed, 12 Apr 2023 15:42:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1681306947; bh=0oGXnOWMD9epxcYMG6dyZUaQf0TCn3MxKgNiJctRdfU=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=FNsoZykaCsajsf78J/LN85dxlxEAyzgAwdaBjY/mkX7uvDGFViwmyvOIU9is5zc2d NyEic3hdV2QjcUjF3YbA32vRoBbSah7Kl0GmspswfHAIDVjUIfWRx0kdaky8vpjJpI ewaGnquho62kziWhKvpcqSKpo0CbepmYFy9qjGsi9twJePy/+tlPgyFKvCuSCFsfRp 1LMHacBs9DkO7N/pC/wFJJGIwlXnorzQjffD1RvW7tVtogcMJKcpRI0+olyuWH5V9Z yqjAdRxvewvFXphUJwttL2e4HqE3TTO85UMkxQZ0oNVMGVBGosKvLBqZ6sNdRHeKje MqMUKeyxVWecw== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4PxP5t57ZYz9rxK; Wed, 12 Apr 2023 15:42:26 +0200 (CEST) In-Reply-To: <83jzyh706c.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 12 Apr 2023 15:30:20 +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:259741 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Eli Zaretskii writes: >> From: Philip Kaludercic >> Cc: Jo=C3=A3o T=C3=A1vora , >> monnier@iro.umontreal.ca, >> 62720@debbugs.gnu.org, larsi@gnus.org >> Date: Wed, 12 Apr 2023 12:00:09 +0000 >>=20 >> > Yes, if Philip and Stefan don't object. But, since there will be a >> > command for updating core packages, doesn't this go against your >> > desire not to change the UX? >>=20 >> After thinking about this for a bit, I think that the right approach is >> to use package-install instead of writing a separate command. After >> all, this will make the behaviour of package-install consistent with >> that of the package menu. > > Is this for master or for the release branch? Personally I am indifferent, it should be compatible with both > And I thought we all agreed built-in packages need special treatment > anyway, didn't we? Then why having a separate command is not a > natural next step? I don't necessarily agree that "special treatment" requires a separate command. I think it is wrong the assume that an built-in package should automatically be updated to a ELPA package whenever possible. It might be that I misunderstood something about your long-term plan where package-install wouldn't suffice. I'll go re-read the thread to check. >> It might work but it should be tested somewhat thoroughly before the >> patch is applied. In the meantime, I just finished a similar approach >> that does not modify `package-installed-p', but just adds another >> utility function: > > A new utility function is fine by me, even if this is e branch. But I > don't quite understand how this is supposed to work in package-install > to allow updating built-in packages, and do that in a way that will > not touch the existing code for non-built-in packages in significant > ways (assuming you propose this from the release branch). Can you > elaborate on that? The only reason we couldn't install built-in packages is that when planning to install packages `package-compute-transaction' believes that if a built-in package is provided, then everything is fine and we don't need to proceed with installing any packages. All I propose is to lift this assumption, then this works fine. One point that might be deliberated is that this means all built-in dependencies are also installed, even if these are not strictly necessary. It shouldn't matter that much, since most users would upgrade them eventually, but worth mentioning I guess?=20 >> +(defun package-core-p (package) >> + "Return non-nil the built-in version of PACKAGE is loaded." > > Didn't you say the "core" terminology was confusing people? TBH I am not really satisfied with the name (so any other suggestion is just as fine for me), and as Joao said it would be better to make the predicate as internal so that users are not expected to deal with it. >> + (let ((package (if (package-desc-p package) >> + (package-desc-name package) >> + package))) >> + (and (assq package (package--alist)) >> + (package-built-in-p package)))) > > It sounds like this doesn't check whether a package is "core", it > checks whether it's built-in and can be updated? So maybe the name > should be changed to reflect that? And the doc string as well (what > it means by "is loaded")? Right the "loaded" doesn't make sense. How about this: --=-=-= Content-Type: text/x-diff Content-Disposition: attachment; filename=0001-Allow-upgrading-built-in-packages.patch >From 12e0b209992675a042112e790571d427a003c30d Mon Sep 17 00:00:00 2001 From: Philip Kaludercic Date: Wed, 12 Apr 2023 14:26:39 +0200 Subject: [PATCH] Allow upgrading built-in packages * lisp/emacs-lisp/package.el (package--upgradable-built-in-p): Add new utility predicate. (package-compute-transaction): Check if an installed package is built-in while resolving dependencies and allow it to be installed. (package-install): Suggest upgrading built-in packages in the interactive specification. Allow upgrading built-in packages --- lisp/emacs-lisp/package.el | 36 ++++++++++++++++++++++++++++++------ 1 file changed, 30 insertions(+), 6 deletions(-) diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el index f92afe56b76..2cf98290bba 100644 --- a/lisp/emacs-lisp/package.el +++ b/lisp/emacs-lisp/package.el @@ -797,6 +797,20 @@ package-built-in-p (require 'finder-inf nil t) ; For `package--builtins'. (assq package package--builtins)))))) +(defun package--upgradable-built-in-p (package) + "Check if a built-in PACKAGE can be upgraded. +This command differs from `package-built-in-p' in that it only +returns a non-nil value if the user has not installed a more +recent version of the package from a package archive." + (and (not (assq (cond + ((package-desc-p package) + (package-desc-name package)) + ((stringp package) (intern package)) + ((symbolp package) package) + ((error "Unknown package format: %S" package))) + (package--alist))) + (package-built-in-p package))) + (defun package--autoloads-file-name (pkg-desc) "Return the absolute name of the autoloads file, sans extension. PKG-DESC is a `package-desc' object." @@ -1908,7 +1922,16 @@ package-compute-transaction (package-version-join (package-desc-version already))))) (cond (already nil) - ((package-installed-p next-pkg next-version) nil) + ;; If a package is installed, we don't need to continue. + ;; Built-in packages constitute an exception, because we want + ;; to allow the user to "upgrade" from a built-in version to a + ;; potentially newer version available on ELPA (bug#62720). + ((and (not (package--upgradable-built-in-p next-pkg)) + (package-installed-p next-pkg next-version))) + ;; The pseudo-package Emacs is always installed and built-in. + ;; It cannot be upgraded, so we make sure not to proceed beyond + ;; this point when resolving dependencies. + ((eq next-pkg 'emacs)) (t ;; A package is required, but not installed. It might also be @@ -2205,11 +2228,12 @@ package-install (package--archives-initialize) (list (intern (completing-read "Install package: " - (delq nil - (mapcar (lambda (elt) - (unless (package-installed-p (car elt)) - (symbol-name (car elt)))) - package-archive-contents)) + (mapcan + (lambda (elt) + (and (or (package--upgradable-built-in-p (car elt)) + (not (package-installed-p (car elt)))) + (list (car elt)))) + package-archive-contents) nil t)) nil))) (package--archives-initialize) -- 2.39.2 --=-=-=--