From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot Date: Tue, 11 Apr 2023 19:31:09 +0100 Message-ID: References: <87a5zj2vfo.fsf@gmail.com> <87wn2modrm.fsf@posteo.net> <87ile6o2ov.fsf@posteo.net> <87y1mz38rl.fsf@posteo.net> <87ile2n0kn.fsf@gmail.com> <83v8i2abqi.fsf@gnu.org> <87wn2ilgx7.fsf@gmail.com> <83a5ze9uc1.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="30627"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, 62720@debbugs.gnu.org, philipk@posteo.net, monnier@iro.umontreal.ca To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Apr 11 20:32:27 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 1pmIn5-0007mi-29 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 11 Apr 2023 20:32:27 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pmImk-0005rH-49; Tue, 11 Apr 2023 14:32:06 -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 1pmImg-0005ph-OG for bug-gnu-emacs@gnu.org; Tue, 11 Apr 2023 14:32: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 1pmImg-0007AH-GA for bug-gnu-emacs@gnu.org; Tue, 11 Apr 2023 14:32:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pmImg-0005c6-Bz for bug-gnu-emacs@gnu.org; Tue, 11 Apr 2023 14:32:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 11 Apr 2023 18:32: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.168123788921538 (code B ref 62720); Tue, 11 Apr 2023 18:32:02 +0000 Original-Received: (at 62720) by debbugs.gnu.org; 11 Apr 2023 18:31:29 +0000 Original-Received: from localhost ([127.0.0.1]:38186 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pmIm9-0005bF-02 for submit@debbugs.gnu.org; Tue, 11 Apr 2023 14:31:29 -0400 Original-Received: from mail-ot1-f44.google.com ([209.85.210.44]:33724) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pmIm6-0005b0-QE for 62720@debbugs.gnu.org; Tue, 11 Apr 2023 14:31:27 -0400 Original-Received: by mail-ot1-f44.google.com with SMTP id i15-20020a9d610f000000b006a11f365d13so3579445otj.0 for <62720@debbugs.gnu.org>; Tue, 11 Apr 2023 11:31:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1681237881; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Ng3osF+I1nPw+caK/E46PyJxyO5Aia1ChtOrsf+4kxs=; b=OnS0BG53k7GQlY6r9qEbtdpa3jGYUtAFzSKNE/r1LDvdav1aJz2MFuizlYAEwzX06n qZ8UdolQQXxM3IscLTfIZdBD0hAkxheVeuVe6VK9VJMKspalu8k7AWXMToMFQ6LnDS9O V1tqj/0MYSPiZqS49XbRFqL111g5RrhP6z1tgtE8HpQJ8sq7MMG7anwjzPY5JMV0zTUN 7GkM23lgrpvFt/Yrs9sewUTGQJNPn34rNcYj5JTT1/lpWHyTz+Um6k7ClVDr2KOnHeyS 4JDFskwX48GCXHNX7MdefOyxy070vKW73q5/+rLp0Q1KXMWTFIuxb5/djWQxBDHVsGVz wfOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1681237881; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Ng3osF+I1nPw+caK/E46PyJxyO5Aia1ChtOrsf+4kxs=; b=eOxLjK3H37e+22K5azZfGb7KDUMIEgywiwmC+NBGYCEiVH207YCVhuuaJV1ugGOdSR /UQmuu08n3CHCdTHriNV8o16ebu+jKmQ7e3a4GdDPU6uTYDn7HN1UsWXiiwyORHJqUNk Vat01Atytba67okA72EHBRI+qI5XYAWbgfISdUGRR+lh0o7liVUM7qlC/N+WChomCPzk 7dIbqb+LIE017p+vqS7LH5C2aVIiVDEcvefhrcbbpa6EusPVaLv0e5yy/RUlIkAedOmu mMH9l8z8EOg0fn1njK/XjyxHWOYGNeB4vqZQjZc3M/R9qgtFHQhAxHpUn5KeRYR1S8Q9 rZhw== X-Gm-Message-State: AAQBX9dZn/HIT+4DnrPzdAYzrxoRGWMU+AjoIdAVPUn9XDo0zn6qAYFF dLYIEJgmNKDuj625uZ7Nw578MVga9B9ZOb0bh+Y= X-Google-Smtp-Source: AKy350bGWLuYOTXB6ot0CC8FO1jLpqDyI2ZAbQ7kVYvPRsdl1+Zjs4aKE1lpNp0x047g8LxpczTllb37ktCxSHJB2RY= X-Received: by 2002:a9d:7f07:0:b0:6a4:1662:8527 with SMTP id j7-20020a9d7f07000000b006a416628527mr158534otq.4.1681237880957; Tue, 11 Apr 2023 11:31:20 -0700 (PDT) In-Reply-To: <83a5ze9uc1.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:259660 Archived-At: On Tue, Apr 11, 2023 at 6:55=E2=80=AFPM Eli Zaretskii wrote: > > Please reconsider. If we do this, than Emacs 29 users will be almost > > locked out of upgrading Eglot and a lot of other built-in packages. > > I'll have to teach people that workaround in the manual, where such > > workarounds don't really belong. > > OK, I looked closer at the patch and the code involved in this, and > also re-read this discussion. I cannot agree with installing your > patch, as submitted, on the emacs-29 branch, sorry. It modifies code > that affects "normal" invocations of package-update, and also numerous > other functions in package.el (via the change in > package--updateable-packages), I don't understand. package--updateable-packages is an internal helper that only has two users, both of which I tested. That's not "numerous". > in ways that are very hard for me to > audit. It is hard to audit because there are parts of it that read > like some kind of "black magic": > > > + (nonbuiltin (assq package package-alist))) > > Why is the return value of assq the sign that the package is > "nonbuiltin"? Because package-alist only contains packages that were installed by the user explicitly. > > > + (cond (nonbuiltin > > + (let ((desc (cadr nonbuiltin))) > > + (if (package-vc-p desc) > > + (package-vc-update desc) > > + (package-delete desc 'force) > > + (package-install package 'dont-select)))) > > + (t > > + (package-install > > + (cadr (assq package package-archive-contents))))))) > > Why the different way of calling package-install for "built-in" > packages? 1. Because built-in packages cannot be deleted. 2. Because built-in packages aren't described the same way that explicitly installed packages. The description of a built-in package is much poorer in information. To make package-install work with a built-in package, you have to give it the richer description of the package that you want to install, fresh from package-archive-contents. > > - (package-desc-version (cadr elt)) > > + (if (vectorp (cdr elt)) > > + (aref (cdr elt) 0) > > + (package-desc-version (cadr elt))) > > What is the significance of the (vectorp (cdr elt)) test? It tells if the current element being iterated has, in its cdr an object of type package--bi-desc. That struct, is implemented via a vector, and so, unfortunately has no recognizer predicate. > > - (package-vc-p (cadr (assq (car elt) package-alist))))) > > - package-alist))) > > + (and (consp (cdr elt)) > > + (package-desc-p (cadr elt)) > > + (package-vc-p (cadr elt))))) > > + (seq-union package-alist package--builtins > > + (lambda (a b) (eq (car a) (car b))))))) > > What is the significance of the (consp (cdr elt)) test? And why do we > need to add package--builtins to the list? package-alist's form is ((SYM PACKAGE-DESC)...) while package--builtins is ((SYM . PACKAGE--BI-DESC) ...) > How am I supposed to assess the safety of this patch, given all this > semi-obfuscated code, and given that I'm not the every-day maintainer > of package.el and am not familiar with all the quirks of its code? > (It is quite possible that this obfuscated nature of the code is not > your fault, but is caused by how package.el is implemented. In which > case I hope that we could clean up the code of package.el on master to > allow updating :core packages more seamlessly and with simpler code.) Yes, quite so. That was my point to Philip earlier: this code is awful to read, but when you read it, you'll notice that it's not really rocket science going on there. That's why I think this is simple enough patch to go for emacs 29. I do hope Stefan and Philip can chime in. Do note that if this change goes to master and not to emacs-29, people will only be effectively testing the new functionality when the emacs-30 branch is cut. > OTOH, the workaround you described in > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D62720#5 > > doesn't sound too awful to me, given that this problem exists for a > while and is not specific to Eglot. As I explained, I don't think there were ever :core packages as popular as Eglot. There is also the fact that many people are using non-package.el package managers, which is a maintenance burden for me. I always recommend package.el, the official package manager, since I don't have the resources to learn about those other package managers (some of which have brought problems in the past). That workaround is awful to use, BTW. It's quite slow, (M-x package-list-packages takes ages, like almost a minute here). Then you have to C-s and find a million false positives eglot-something packages and then you have to know the `i` and `x` shortcuts, which aren't really something Emacs newcomers know about. On the other hand, M-x package-update gives you a completion list of the packages you have already. > See above. Given the problems I mentioned, I'm allowed to doubt that > you yourself understand the changes well enough to vouch for them. > And even if you did vouch, my gray hair won't believe you. So I > prefer to go for much safer, if slightly less clean, changes. I hope > one of the two alternatives I suggested will be acceptable. If this change can't go into emacs-29, I think it's better to add an M-x eglot-update to eglot.el. That's discoverable, easy to remember and the absolute safest, as package.el is absolutely unchanged. (defun eglot-update () "Update Eglot to latest version." (interactive) (unless package-archive-contents (package-refresh-contents)) (package-install (assq 'eglot package-archive-contents))) Jo=C3=A3o