Search and Install do not return the same results

[Trenly]

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

[jedieaston]

It looks like searches sent to a REST source look in specific fields when a search is ran for winget install, and those fields are not specified for winget search.

The body of the request for winget search wireshark:

{
   "Filters":[
      {
         "PackageMatchField":"Market",
         "RequestMatch":{
            "KeyWord":"US",
            "MatchType":"CaseInsensitive"
         }
      }
   ],
   "Query":{
      "KeyWord":"wireshark",
      "MatchType":"Substring"
   }
}

And the body of the request for winget install wireshark:

{
   "Filters":[
      {
         "PackageMatchField":"Market",
         "RequestMatch":{
            "KeyWord":"US",
            "MatchType":"CaseInsensitive"
         }
      }
   ],
   "Inclusions":[
      {
         "PackageMatchField":"PackageFamilyName",
         "RequestMatch":{
            "KeyWord":"wireshark",
            "MatchType":"Exact"
         }
      },
      {
         "PackageMatchField":"ProductCode",
         "RequestMatch":{
            "KeyWord":"wireshark",
            "MatchType":"Exact"
         }
      },
      {
         "PackageMatchField":"PackageIdentifier",
         "RequestMatch":{
            "KeyWord":"wireshark",
            "MatchType":"CaseInsensitive"
         }
      },
      {
         "PackageMatchField":"PackageName",
         "RequestMatch":{
            "KeyWord":"wireshark",
            "MatchType":"CaseInsensitive"
         }
      },
      {
         "PackageMatchField":"Moniker",
         "RequestMatch":{
            "KeyWord":"wireshark",
            "MatchType":"CaseInsensitive"
         }
      }
   ]
}

Either there's something weird about the Store source's search where nothing happens if there's not a field set, or (more likely based on my mild knowledge) the use of MatchType: Substring instead of MatchType: CaseInsensitive is causing the searches to be tighter than they intended them to be.

[denelon]

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.

[Masamune3210]

Definitely running into this, even specifying the id doesn't disambiguate it enough

[Trenly]

Definitely running into this, even specifying the id doesn't disambiguate it enough

Use the —id parameter specifier as a temporary workaround

[Jaifroid]

@Masamune3210 The ID could be case-sensitive. You wrote gog.galaxy whereas the ID is GOG.Galaxy. At least check if that might be an issue.

[Masamune3210]

From what I've seen install usually works with case-insensitivity but tried anyway, no dice

[derekwilling]

winget install GOG.Galaxy -s winget is a workaround also.

I ran into similar issue trying to install MS Teams:

❯ winget --version
v1.1.12653

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

[peter-dolkens]

msstore is definitely causing issues here - you don't even get the same (incorrect) results between runs

C:\Users\peter>winget install Microsoft.VisualStudioCode
Multiple packages found matching input criteria. Please refine the input.
Name                         Id                         Source
---------------------------------------------------------------
Microsoft Whiteboard         9MSPC6MP8FM4               msstore
Microsoft Visual Studio Code Microsoft.VisualStudioCode winget

C:\Users\peter>winget install "Microsoft.VisualStudioCode"
Multiple packages found matching input criteria. Please refine the input.
Name                               Id                         Source
---------------------------------------------------------------------
Microsoft Wireless Display Adapter 9WZDNCRFJBB1               msstore
Microsoft Visual Studio Code       Microsoft.VisualStudioCode winget

[jedieaston]

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, run winget source reset.

Here's some more info: #1515 (comment)

[denelon]

I've covered a few tips in the blog for Windows Package Manager 1.1.

[Jaifroid]

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 and winget show should return the same results, in my opinion. If I type winget show kiwix, I expect it to show details of the package that will install if I then type winget install kiwix. Unfortunately these commands are currently broken if a moniker is defined: see #1568.

[peter-dolkens]

I feel like there should be a "default" store that is given precedence

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

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.

[denelon]

We're aware of what is causing this issue. We have changes planned early next week to improve this.

[denelon]

Fortunately, this is a back-end change and doesn't require client changes. I thought I'd share this bit of information.

[denelon]

This didn't make the 10/18 target date. I'm chasing the next date down.

[denelon]

It looks like 10/25 is the next release window we're targeting.

[jedieaston]

Don't mean to bump, but has anything happened on this?

[denelon]

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.

[denelon]

This change is starting to roll out. It's likely to take a day to completely roll out globally.

[denelon]

I was just informed the deployment has completed.

[Jaifroid]

@denelon, why am I still getting this result when I run winget install kiwix? kiwix is a unique moniker, so I expect it to select the package based on the moniker. Monikers should have the highest priority, or else what are they for?

The other package listed here is completely random, as you can see from the result of winget search kiwix below. Why has it picked one WikiMed package from the msstore, and not, say, the Kiwix JS package from the store?

IMHO this issue is not fixed, and should be re-opened. I want to be able to tell my users that they can install my app very simply by typing winget install kiwix, as used to be the case. I should not expect them to have to remember obscure switches like -s winget added on the end.

[Masamune3210]

It's not a unique moniker if the word is in 7 different packages. That's like saying Java is unique even though it's in multiple package titles

[Jaifroid]

@Masamune3210 I beg to differ. We have the option of defining a moniker in the manifest, precisely to act as a shorthand. I publish all of the above packages, and I have given unique monikers to each of the packages in the winget repository. I used to be able to install each of them with these monikers:

winget install kiwix - Installed package Kiwix.KiwixJS
winget install wikimed - Installed package Kiwix.WikiMed
winget install wikivoyage - Installed package Kiwix.Wikivoyage

So, tell me, what is the moniker definition for in the manifest if it is not intended to act as a shorthand for a package ID? I repeat, monikers should have the highest priority in selecting a package. Tags are for searching. I have no quarrel with the search results. My problem is with the install (and show) results.

[denelon]

@Jaifroid the store source doesn't support moniker yet. This issue was about getting the "winget install" command to at least match consistently with results from "winget search". We're still working on additional improvements and customizations for behavior with other Issues here at GitHub for the client, and internally with the Microsoft Store source.

The moniker is intended to act as a shortcut. With two sources it's a bit more challenging. There is an order of precedence from the ID, Name,, and Moniker in the default "winget" source. We're looking at some additional heuristics to help when we get a result from more than one source. Since a moniker wouldn't be unique across multiple sources, we're looking to extend the behavior a bit further with preferences on source priority as well.

[Jaifroid]

@denelon, that would be very helpful. In the case of winget install kiwix, two packages are returned, one from the winget repository with a moniker of 'kiwix', and one from the msstore source, with no moniker. It seems "obvious" that a package from the winget source with a fully matching moniker should trump a package from the msstore source with only a partial match on the package name. But I know that coding these behaviours is complex, given the number of edge cases.