GNU bug report logs - #75490
30.0.93; package-upgrade-all - show upgradeable packages

Previous Next

To reply to this bug, email your comments to 75490 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.93; package-upgrade-all - show upgradeable packages
Date: Sat, 11 Jan 2025 12:23:42 +0100

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

Message #8 received at 75490 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 75490 <at> debbugs.gnu.org, Philip Kaludercic <philipk <at> posteo.net>,
 Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#75490: 30.0.93;
 package-upgrade-all - show upgradeable packages
Date: Sat, 11 Jan 2025 06:37:52 -0500

[Message part 1 (text/plain, inline)]

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 <at> 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
>
>
>
>

[Message part 2 (text/html, inline)]

Message #11 received at 75490 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Ship Mints <shipmints <at> gmail.com>
Cc: 75490 <at> debbugs.gnu.org, Philip Kaludercic <philipk <at> posteo.net>,
 Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#75490: 30.0.93; package-upgrade-all - show upgradeable
 packages
Date: Sat, 11 Jan 2025 12:55:31 +0100

Ship Mints <shipmints <at> 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

Message #14 received at 75490 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: 75490 <at> debbugs.gnu.org
Cc: Philip Kaludercic <philipk <at> posteo.net>,
 Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#75490: 30.0.93; package-upgrade-all - show upgradeable
 packages
Date: Sun, 12 Jan 2025 22:00:23 +0100

[Message part 1 (text/plain, inline)]

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

[0001-package-upgrade-all-Show-list-of-upgradeable-package.patch (text/x-diff, attachment)]

Message #17 received at 75490 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 75490 <at> debbugs.gnu.org, philipk <at> posteo.net, stefankangas <at> gmail.com
Subject: Re: bug#75490: 30.0.93;
 package-upgrade-all - show upgradeable packages
Date: Mon, 13 Jan 2025 14:24:08 +0200

> Cc: Philip Kaludercic <philipk <at> posteo.net>,
>  Stefan Kangas <stefankangas <at> 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 <at> 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?

Message #20 received at 75490 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 75490 <at> debbugs.gnu.org, philipk <at> posteo.net, stefankangas <at> gmail.com
Subject: Re: bug#75490: 30.0.93; package-upgrade-all - show upgradeable
 packages
Date: Mon, 13 Jan 2025 13:47:02 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Cc: Philip Kaludercic <philipk <at> posteo.net>,
>>  Stefan Kangas <stefankangas <at> 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 <at> 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

Message #23 received at 75490 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 75490 <at> debbugs.gnu.org, philipk <at> posteo.net, stefankangas <at> gmail.com
Subject: Re: bug#75490: 30.0.93; package-upgrade-all - show upgradeable
 packages
Date: Mon, 13 Jan 2025 15:32:03 +0200

> From: Daniel Mendler <mail <at> daniel-mendler.de>
> Cc: 75490 <at> debbugs.gnu.org,  philipk <at> posteo.net,  stefankangas <at> gmail.com
> Date: Mon, 13 Jan 2025 13:47:02 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> Cc: Philip Kaludercic <philipk <at> posteo.net>,
> >>  Stefan Kangas <stefankangas <at> 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 <at> 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.

Message #26 received at 75490 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 75490 <at> debbugs.gnu.org, Daniel Mendler <mail <at> daniel-mendler.de>,
 stefankangas <at> gmail.com
Subject: Re: bug#75490: 30.0.93; package-upgrade-all - show upgradeable
 packages
Date: Mon, 13 Jan 2025 13:50:44 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Daniel Mendler <mail <at> daniel-mendler.de>
>> Cc: 75490 <at> debbugs.gnu.org,  philipk <at> posteo.net,  stefankangas <at> gmail.com
>> Date: Mon, 13 Jan 2025 13:47:02 +0100
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> >> Cc: Philip Kaludercic <philipk <at> posteo.net>,
>> >>  Stefan Kangas <stefankangas <at> 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 <at> 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.

Message #29 received at 75490 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: 75490 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, stefankangas <at> gmail.com
Subject: Re: bug#75490: 30.0.93; package-upgrade-all - show upgradeable
 packages
Date: Thu, 16 Jan 2025 13:48:39 +0100

Philip Kaludercic <philipk <at> posteo.net> writes:

>>> 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.

Agree. It is a bit unfortunate that there isn't a helper function for
such prompts with a popup window. Such a popup appears at least in
Dired/Ibuffer when deleting/killing multiple files/buffers. Could be
that there are even more instances. Might be good to extract the common
functionality?

Daniel

Message #32 received at 75490 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Daniel Mendler <mail <at> daniel-mendler.de>,
 Philip Kaludercic <philipk <at> posteo.net>
Cc: 75490 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#75490: 30.0.93;
 package-upgrade-all - show upgradeable packages
Date: Fri, 24 Jan 2025 17:58:44 -0600

Daniel Mendler <mail <at> daniel-mendler.de> writes:

> Philip Kaludercic <philipk <at> posteo.net> writes:
>
>>>> 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.
>
> Agree. It is a bit unfortunate that there isn't a helper function for
> such prompts with a popup window. Such a popup appears at least in
> Dired/Ibuffer when deleting/killing multiple files/buffers. Could be
> that there are even more instances. Might be good to extract the common
> functionality?

+1 on using a buffer for this (when I upgrade, I do 50+ packages in one
go), and on extracting the common functionality (because I've needed it
myself in the past and had to reimplement).

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.