microsoft / winget-cli

WinGet is the Windows Package Manager. This project includes a CLI (Command Line Interface), PowerShell modules, and a COM (Component Object Model) API (Application Programming Interface).
https://learn.microsoft.com/windows/package-manager/
MIT License
23.1k stars 1.44k forks source link

Output of the `upgrade` command should be sorted alphabetically #1352

Open danstis opened 3 years ago

danstis commented 3 years ago

Description of the new feature/enhancement

The output seems to be in no meaningful order when running winget upgrade to list all packages with updates. I believe it would be easier to read the output if this was sorted alphabetically by Name or Id.

I understand the similarity to this issue #142 however I believe the upgrade command does not have to sort by relevancy, as the packages are already installed.

Proposed technical implementation details (optional)

The output of the winget upgrade command to be sorted alphabetically by Name,

Karl-WE commented 3 years ago

Please consider the same for Winget install. Eventually include more sorting options like in PowerShell Sort-Table new perferred default for install / upgrade:

sort by name ascending (alphabetically not alphanumerically)

add new options for sorting

Example 1: winget list --sort [ColumnName]

[ColumnName]: Name, ID, Version, InstallDate (respect windows regional settings)

as a sub command of --sort --ascending (default if not specified) / --descending

as a sub command of --sort --numeric / --alphabetical (default if not specified)

Example 2:

winget list --sort Version --descending --numeric

result: lists all installed packages found in winget repo sorted by column name descending (numerically)

Example 3: winget upgrade --sort Name --ascending --alphabetical

aka

winget upgrade --sort

(Name --acending --alphabetically could be ommited as they are default)

result: lists all upgradeable packages found in winget repo sorted by column name ascending (alphabetically)

@denelon there might be thoughts about what will be the short commands for --sort as it cannot be -s for certain conflicts (foremost logical -s should mean silent)

However as we see --tags has no short command I do not think that --sort needs a short command. Eventually we could abbreviate

Proposal of commands

-st / --sort

-asc / --ascending used with sort, sorts in ascending mode (default for sort if not specified)

-desc / --descending used with sort, sorts in descending mode

-num / --numeric used with sort, sorts (alpha)numeric

-al / --alphabetical used with sort, sorts alphabetically (default for sort if not specified)

denelon commented 3 years ago

Did you mean winget list for Example 1?

Upgrade makes sense.

Yes, I've got a few different suggestions for the single character shortcuts. I think this would be breaking, so renaming things might be a 2.0 milestone. For the sake of clarity, I wouldn't necessarily wait for a specific date to have a breaking semver version. We're heads down on 1.1 right now.

There are some other defaults people have asked for like "silent" install vs. "silent with progress". I think the upcoming PowerShell nouns and verbs may also influence the future direction in some cases.

Karl-WE commented 3 years ago

Oh it was late. Certainly meant list, not install. Thank you for spotting this @denelon Corrected the examples.

Karl-WE commented 3 years ago

@denelon have added some proposals for short commands as I think it could take a longer time before winget does work with PowerShell.

Would these be compatible?

denelon commented 3 years ago

@chausner I remember you started a draft PR for sorting search output. Would you be interested in looking at sorting list and/or upgrade output? I am good with all of the "long" "--" arguments suggested by @Karl-WE. I'm still on the fence about the "short" "-" arguments. We've been restricting them to a single letter, but I think we need further discussion regarding multiple character short arguments. That's a departure from the current UX.

@JohnMcPMS do you see any concerns with this? I just wanted to make sure you don't have any refactoring or other changes in mind that might have potential conflicts.

Karl-WE commented 3 years ago

Thank you @denelon As for the commands I want to bring a new old thing to the table. It is commonly in configuration of network devices (switches etc.)

You can either use the full command like

Show interface brief Or sh int br

Another example from a MSFT team is diskpart.

Select volume c Or Sel vol c Or sele volume c Etc.

The beauty here it is upon the user that can shorten any commands in any combination until it is getting ambigous and is reported to be in this case.

I don't want to derail from the original PR but if you and the team thinks this could ease things, I would create a new one.

denelon commented 3 years ago

@Karl-WE those are both great examples.

I'll talk with the team to see if we have any policies/guidance in this area. I need to make sure there aren't any "newer" standards we'd be violating. In general, we don't like making breaking changes, and we have a long tradition of extended compatibility. This could have far reaching consequences in terms of having tuples for commands and arguments. I use the PowerShell autocomplete feature to help minimize typing myself.

Karl-WE commented 3 years ago

Absolutely agree. Switches do support auto completion with tab.

Yet in the light of PowerShell "conformity" we should keep the - or -- writing style. It doesn't necessarily conflict with the abbreviations as shown above.

Even though this is not working in PowerShell that you can short the commands anywhere, it might help to end the conflict of how to actively design and maintain short commands.

In PowerShell there is just omitting commands that are default input or aliases like gci or ft, select. But they would need to maintained more as the other method.

JohnMcPMS commented 3 years ago

Regarding short options, the code currently supports only a single character. It actually supports chaining multiple short options together, like winget install Foo -ie for winget install Foo --interactive --exact. Supporting more than one character would break that.

As for allowing "starts with" semantics for commands and long options, I don't see any reasons why we couldn't.

Sorting being applied upon request on any of the commands that output a table of results seems fine. The argument parsing code doesn't preserve ordering right now though, so making options apply to other options would require infrastructure work. My opinion is to let that wait for PowerShell, but if someone submitted a quality change I wouldn't reject it.

To the original request, I think it would be perfectly fine to have the list (no search term) and upgrade commands sort the output by name by default. I think @chausner 's draft could be adapted to handle that in those scenarios.

Trenly commented 1 year ago

[Policy] Area-Output [Policy] Area-Sorting

klacol commented 1 year ago

The standard of winget list order should be ordered alphabetically ascending by Name. I do net get my head around, how I am supposed to find value in the list, when I can not find a program, from which I do not know the Name. It should be like in "List of installed Apps" which is sorted properly and helps me to understand, which apps are installed on my machine.

SpoonOfDoom commented 8 months ago

Agreed, currently the list is borderline useless when you have more than 10-20 entries.