bug#75490: 30.0.93; package-upgrade-all - show upgradeable packages

bug#75490: 30.0.93; package-upgrade-all - show upgradeable packages

[Daniel Mendler via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Currently `package-upgrade-all' displays the number of packages to
upgrade. I suggest to instead show a list of the names of the packages
which are about to be upgraded. This way the user has a better chance to
review the packages before they get installed. Of course the user can
have better control by going via the `list-packages' interface. However
I argue that package.el should not offer UIs and confirmations which
omit relevant information in order to improve security.

The current `package-upgrade-all' confirmation is as follows:

(when (and query
           (not (yes-or-no-p
                 (if (length= upgradeable 1)
                     "One package to upgrade.  Do it? "
                   (format "%s packages to upgrade.  Do it?"
                           (length upgradeable))))))
  (user-error "Upgrade aborted"))

I suggest to replace it with this:

(when (and query
           (not (yes-or-no-p
                 (format
                  "Upgrade %s?"
                  (mapconcat #'symbol-name upgradeable ", ")))))
  (user-error "Upgrade aborted"))

If the list gets too long, a popup window could be used. See also the
related bug#74604 regarding diffs on package upgrade.

Daniel

bug#75490: 30.0.93; package-upgrade-all - show upgradeable packages

[Ship Mints]

[-- Attachment #1: Type: text/plain, Size: 2137 bytes --]

package-upgrade, when invoked interactively, does show the list of
upgradeable packages. When combined with a decent minibuffer completion
configuration (like Daniel's Vertico), I can cherry-pick or select all. I
agree package-update-all has a poor interface and I do not use it.
package-upgrade perhaps should also refresh the package list when called
interactively and suppress that behavior with a prefix argument.

In the security vein, package-upgrade commands could also show both the
current version(s) and the target version(s) which would be convenient and
assist people willing to put in the work to actually look at package
sources before they upgrade.

On Sat, Jan 11, 2025 at 6:25 AM Daniel Mendler via Bug reports for GNU
Emacs, the Swiss army knife of text editors <bug-gnu-emacs@gnu.org> wrote:

> Currently `package-upgrade-all' displays the number of packages to
> upgrade. I suggest to instead show a list of the names of the packages
> which are about to be upgraded. This way the user has a better chance to
> review the packages before they get installed. Of course the user can
> have better control by going via the `list-packages' interface. However
> I argue that package.el should not offer UIs and confirmations which
> omit relevant information in order to improve security.
>
> The current `package-upgrade-all' confirmation is as follows:
>
> (when (and query
>            (not (yes-or-no-p
>                  (if (length= upgradeable 1)
>                      "One package to upgrade.  Do it? "
>                    (format "%s packages to upgrade.  Do it?"
>                            (length upgradeable))))))
>   (user-error "Upgrade aborted"))
>
> I suggest to replace it with this:
>
> (when (and query
>            (not (yes-or-no-p
>                  (format
>                   "Upgrade %s?"
>                   (mapconcat #'symbol-name upgradeable ", ")))))
>   (user-error "Upgrade aborted"))
>
> If the list gets too long, a popup window could be used. See also the
> related bug#74604 regarding diffs on package upgrade.
>
> Daniel
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 2859 bytes --]

bug#75490: 30.0.93; package-upgrade-all - show upgradeable packages

[Daniel Mendler via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Ship Mints <shipmints@gmail.com> writes:

> package-upgrade, when invoked interactively, does show the list of
> upgradeable packages. When combined with a decent minibuffer completion
> configuration (like Daniel's Vertico), I can cherry-pick or select
> all.

Yes, multi-action works with Vertico+Embark. However in my Emacs
`package-upgrade' shows more than the list of upgradeable archive
packages, such that I am not using this due to the noise. Also
`embark-act-all' cannot be used.

I just took another look, `package-upgrade' shows upgradeable built-in
packages. I really never want to upgrade them. I don't have package.el
configured to upgrade built-ins, so why are they shown? Is this a bug in
`package-upgrade'?

For this reason I use my own `package-upgrade-all' command variant which
shows me a list of packages, instead of the insufficient confirmation
with only the number of upgradeable packages - this is what this minor
issue is about.

> In the security vein, package-upgrade commands could also show both the
> current version(s) and the target version(s) which would be convenient and
> assist people willing to put in the work to actually look at package
> sources before they upgrade.

Agree. Regarding showing the sources, I've mentioned bug#74604. My
preferred upgrade workflow would go via `package-upgrade-all'. Confirm
the list of packages at the beginning and then for each package confirm
the diff.

Daniel

bug#75490: 30.0.93; package-upgrade-all - show upgradeable packages

[Daniel Mendler via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 164 bytes --]

I've attached a patch to this mail. The yes-or-no-p function handles
longs strings well, such that this works even if there are many
upgradeable packages.

Daniel


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-package-upgrade-all-Show-list-of-upgradeable-package.patch --]
[-- Type: text/x-diff, Size: 1330 bytes --]

From ac5662962a94f5457d6d9287161a08b6401c5b83 Mon Sep 17 00:00:00 2001
From: Daniel Mendler <mail@daniel-mendler.de>
Date: Sun, 12 Jan 2025 21:54:43 +0100
Subject: [PATCH] package-upgrade-all: Show list of upgradeable packages

Instead of only displaying the number of upgradeable packages,
display the package names for the user to check.

* lisp/emacs-lisp/package.el (package-upgrade-all): Show list of
upgradeable packages.
---
 lisp/emacs-lisp/package.el | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el
index b62d026f6ff..450e1dcd00e 100644
--- a/lisp/emacs-lisp/package.el
+++ b/lisp/emacs-lisp/package.el
@@ -2322,10 +2322,9 @@ package-upgrade-all
         (message "No packages to upgrade")
       (when (and query
                  (not (yes-or-no-p
-                       (if (length= upgradeable 1)
-                           "One package to upgrade.  Do it? "
-                         (format "%s packages to upgrade.  Do it?"
-                                 (length upgradeable))))))
+                       (format
+                        "Upgrade %s?"
+                        (mapconcat #'symbol-name upgradeable ", ")))))
         (user-error "Upgrade aborted"))
       (mapc #'package-upgrade upgradeable))))
 
-- 
2.45.2

bug#75490: 30.0.93; package-upgrade-all - show upgradeable packages

[Eli Zaretskii]

> Cc: Philip Kaludercic <philipk@posteo.net>,
>  Stefan Kangas <stefankangas@gmail.com>
> Date: Sun, 12 Jan 2025 22:00:23 +0100
> From:  Daniel Mendler via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> I've attached a patch to this mail. The yes-or-no-p function handles
> longs strings well, such that this works even if there are many
> upgradeable packages.

Do people happen to upgrade dozens of packages in one go?  If that
happens, won't this change in behavior annoy people?  E.g., if the
list is VERY long, we by default show only its last portion that the
mini-window can accommodate after resizing it to the limit, so the
"Upgrade" part might not be visible at all.

Did you consider making this opt-in?

bug#75490: 30.0.93; package-upgrade-all - show upgradeable packages

[Daniel Mendler via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: Philip Kaludercic <philipk@posteo.net>,
>>  Stefan Kangas <stefankangas@gmail.com>
>> Date: Sun, 12 Jan 2025 22:00:23 +0100
>> From:  Daniel Mendler via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>> 
>> I've attached a patch to this mail. The yes-or-no-p function handles
>> longs strings well, such that this works even if there are many
>> upgradeable packages.
>
> Do people happen to upgrade dozens of packages in one go?  If that
> happens, won't this change in behavior annoy people?  E.g., if the
> list is VERY long, we by default show only its last portion that the
> mini-window can accommodate after resizing it to the limit, so the
> "Upgrade" part might not be visible at all.
>
> Did you consider making this opt-in?

We can make this opt-in if this is preferred. Another option would be to
automatically show a longer list in a larger separate window. But in my
tests it worked well with yes-or-no-p alone despite a long list of
package names.

Daniel

bug#75490: 30.0.93; package-upgrade-all - show upgradeable packages

[Eli Zaretskii]

> From: Daniel Mendler <mail@daniel-mendler.de>
> Cc: 75490@debbugs.gnu.org,  philipk@posteo.net,  stefankangas@gmail.com
> Date: Mon, 13 Jan 2025 13:47:02 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Cc: Philip Kaludercic <philipk@posteo.net>,
> >>  Stefan Kangas <stefankangas@gmail.com>
> >> Date: Sun, 12 Jan 2025 22:00:23 +0100
> >> From:  Daniel Mendler via "Bug reports for GNU Emacs,
> >>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> >> 
> >> I've attached a patch to this mail. The yes-or-no-p function handles
> >> longs strings well, such that this works even if there are many
> >> upgradeable packages.
> >
> > Do people happen to upgrade dozens of packages in one go?  If that
> > happens, won't this change in behavior annoy people?  E.g., if the
> > list is VERY long, we by default show only its last portion that the
> > mini-window can accommodate after resizing it to the limit, so the
> > "Upgrade" part might not be visible at all.
> >
> > Did you consider making this opt-in?
> 
> We can make this opt-in if this is preferred.

I think I'd prefer that, but let's see what others think.

Philip, WDYT?

> Another option would be to automatically show a longer list in a
> larger separate window. But in my tests it worked well with
> yes-or-no-p alone despite a long list of package names.

I think we should indeed pop up a buffer, since the mini-window is
limited in how much it can show conveniently.

bug#75490: 30.0.93; package-upgrade-all - show upgradeable packages

[Philip Kaludercic]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Daniel Mendler <mail@daniel-mendler.de>
>> Cc: 75490@debbugs.gnu.org,  philipk@posteo.net,  stefankangas@gmail.com
>> Date: Mon, 13 Jan 2025 13:47:02 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> Cc: Philip Kaludercic <philipk@posteo.net>,
>> >>  Stefan Kangas <stefankangas@gmail.com>
>> >> Date: Sun, 12 Jan 2025 22:00:23 +0100
>> >> From:  Daniel Mendler via "Bug reports for GNU Emacs,
>> >>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>> >> 
>> >> I've attached a patch to this mail. The yes-or-no-p function handles
>> >> longs strings well, such that this works even if there are many
>> >> upgradeable packages.
>> >
>> > Do people happen to upgrade dozens of packages in one go?  If that
>> > happens, won't this change in behavior annoy people?  E.g., if the
>> > list is VERY long, we by default show only its last portion that the
>> > mini-window can accommodate after resizing it to the limit, so the
>> > "Upgrade" part might not be visible at all.
>> >
>> > Did you consider making this opt-in?
>> 
>> We can make this opt-in if this is preferred.
>
> I think I'd prefer that, but let's see what others think.
>
> Philip, WDYT?
>
>> Another option would be to automatically show a longer list in a
>> larger separate window. But in my tests it worked well with
>> yes-or-no-p alone despite a long list of package names.
>
> I think we should indeed pop up a buffer, since the mini-window is
> limited in how much it can show conveniently.

I am a bit short on time to review this right now, but I agree that a
pop-up buffer seems like a better option.  Resizing the minibuffer can
get annoying and difficult to keep an overview, whereas a little table
with an overview of the changes seems more approachable.