winget-cli: Search and Install do not return the same results
Brief description of your issue
Steps to reproduce
run winget search wireshark
run winget install wireshark
Expected behavior
If only one package is returned from search, only one package should be returned for install. Search and install should return the same available packages
Actual behavior
PS C:\WINDOWS\system32> winget search wireshark
Name Id Version Source
-------------------------------------------------------
Wireshark WiresharkFoundation.Wireshark 3.4.8.0 winget
PS C:\WINDOWS\system32> winget install wireshark
Multiple packages found matching input criteria. Please refine the input.
Name Id Source
-----------------------------------------------------------
Computer Networks One 9NC6N8L4T5WS msstore
Wireshark WiresharkFoundation.Wireshark winget
Environment
PS C:\WINDOWS\system32> winget --info
Windows Package Manager v1.1.12653
Copyright (c) Microsoft Corporation. All rights reserved.
Windows: Windows.Desktop v10.0.19043.1237
Package: Microsoft.DesktopAppInstaller v1.16.12653.0
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 3
- Comments: 29 (17 by maintainers)
Commits related to this issue
- Workaround microsoft/winget-cli#1523 (#820) — committed to lutzroeder/netron by lutzroeder 3 years ago
Fortunately, this is a back-end change and doesn’t require client changes. I thought I’d share this bit of information.
I don’t know why, but this one cracked me up:
“Hi! I’m a Microsoft utility! You want Office? Have you tried ‘not Office’?”
This didn’t make the 10/18 target date. I’m chasing the next date down.
Quick update. We’re going to test some of the changes this week and anticipate a release as early as October 18th (+ or - a day depending on geography).
If this is causing too many issues for you run
winget source remove msstore
to use the community repo only. If you want to try it again, runwinget source reset
.Here’s some more info: https://github.com/microsoft/winget-cli/discussions/1515#discussioncomment-1398086
msstore is definitely causing issues here - you don’t even get the same (incorrect) results between runs
The store source is approximating the REST API calls. We’ve got another change to hopefully bring the results of search and install to a more consistent state.
winget install GOG.Galaxy -s winget
is a workaround also.I ran into similar issue trying to install MS Teams:
I know this may not be the place to ask this, but is there a way to remove
msstore
as a source?I found the answer to my question. You can remove the msstore source and avoid these issues. Open elevated shell and run
winget source remove msstore
I was just informed the deployment has completed.
This change is starting to roll out. It’s likely to take a day to completely roll out globally.
Thanks for bumping. We’re testing in PPE currently, and this will have a staged roll out based on geography. The roll out is scheduled to start on 10/28.
It looks like 10/25 is the next release window we’re targeting.
We’re aware of what is causing this issue. We have changes planned early next week to improve this.
I feel like there should be a “default” store that is given precedence
I’d go one step further to say that the “default” repository should be user-selectable, and that an exact-match of product id should always work if it’s unique, or if it’s available in the default repository.
If I’m adding custom/additional repositories, I don’t expect them to interfere with my “default” behavior.
I actually think “search” and “install” should not return the same results.
winget search
should be a wide-ranging search that matches anything in product ID, moniker or package name.winget install
should give precedence to any moniker that has been defined (and monikers should be unique). If the install request does not match a defined moniker, then it should attempt to match by product id (this will give precedence to the winget repository, because msstore product IDs are random strings of letters).On the other hand,
winget install
andwinget show
should return the same results, in my opinion. If I typewinget show kiwix
, I expect it to show details of the package that will install if I then typewinget install kiwix
. Unfortunately these commands are currently broken if a moniker is defined: see #1568.I’ve covered a few tips in the blog for Windows Package Manager 1.1.
@Masamune3210 The ID could be case-sensitive. You wrote
gog.galaxy
whereas the ID isGOG.Galaxy
. At least check if that might be an issue.Definitely running into this, even specifying the id doesn’t disambiguate it enough