-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Add filter-by install scope (user/machine) for List and Search#6044
Add filter-by install scope (user/machine) for List and Search #6044IDisposable wants to merge 1 commit intomicrosoft:master from
Conversation
This comment has been minimized.
This comment has been minimized.
0e6ba61 to
a30f1aa
Compare
This comment has been minimized.
This comment has been minimized.
Also fix the filter-by source for List to work. Added parameter to Get-WinGetPackage for install scope and pass it down to the filters sent to WinGet CLI.
a30f1aa to
51b06c9
Compare
IDisposable
commented
Feb 12, 2026
Unrecognized words (1)
pagckages
Oops, fixed and force-pushed
@JohnMcPMS
JohnMcPMS
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is no actual change to behavior presented here (save potential improvements to completion). Filtering by scope is already present on list and adding it to search will require significant investment, including placing the scope into the index.
Filtering the list output based on the source parameter is achievable with a client only change, but this PR doesn't actually do what is needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is false; the parameter was used inconsistently from how it would seem most people expected (but very consistently with the rest of the command workflows).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When calling the Powershell API, it sure doesn't seem to filter by scope. My goal is to find all the user-scoped, winget-installed packages and reinstall them as machine-scoped if possible. Trying to script in Powershell...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Additionally, just accepting the parameter is unlikely to have the desired effect on the downstream workflow. search in particular intentionally avoids accessing the manifest, which is currently the only way to know available scopes and thus filter the results.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair point. I was really only concerned with pulling a list to make an script to do an automated "user" to "machine" reinstall. I'll pull the search changes :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This file is not used; the PowerShell is all C# in \src\PowerShell.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like that should be removed then? Seems really confusing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
list already accepted scope.
IDisposable
commented
Feb 14, 2026
Filtering the
listoutput based on the source parameter is achievable with a client only change, but this PR doesn't actually do what is needed.
What, beyond doing the same logic as the source is needed? https://github.com/microsoft/winget-cli/pull/6044/changes#diff-2cf6f75aa8aad569ed10c9f32e985e9348f431490438e7361d4a484c80050dceR66
Uh oh!
There was an error while loading. Please reload this page.
Fixes #6045 and Implements #4236 (summarized in #1155), #6046, and #6047
Microsoft Reviewers: Open in CodeFlow