Specifying a package doesnt help when multiple packages are found

[derkrasseleo]

Brief description of your issue

When I have to specify a package name when installing, winget asks for the package name over and over again.

Steps to reproduce

winget install <package> firefox is just an example

Expected behavior

Just install the specified package?!

When I try to install a package and don't know the exact package name there should be an input choice (1,2,3) for which one I want to install, like with many Linux package managers.

Actual behavior

Asks again, which package I want to install, even if the package name is unique!

Environment

[winget --info]
Windows Package Manager v1.1.12663
Windows: Windows.Desktop v10.0.22000.194
Package: Mozilla.Firefox (for example)

[derkrasseleo]

I just noticed winget found two different packages, even though the input was the same?!

[derkrasseleo]

Spotify also has this behavior.

[ahmedadan]

Having the same issues on Windows 11 and winget v1.1.12702

[Jaifroid]

I'm now seeing this behaviour also with my Kiwix JS package. I have defined a moniker "kiwix", and I expect it to be unique. Until very recently, a user could type winget install kiwix and the package would begin to install. Now, instead, the user will get this:

A naïve user will not know how to proceed. If I have defined a moniker, I expect it to take precedence over an arbitrary match in the MS Store. The matching here is arbitrary because it doesn't pick up the other packages we have in MS Store which are "Kiwix JS", "Wikivoyage by Kiwix" and "WikiMed by Kiwix". These packages are correctly picked up by winget search kiwix (this works as expected).

Note that winget show kiwix is also broken: it shows the disambiguate request when it should select any unique moniker.

[Jaifroid]

This issue seems to be similar to #1523, but not exactly the same. It may have the same cause.

[jedieaston]

This is mostly because the Microsoft Store's search isn't good (#1523 is the right issue, I believe).

You can bypass it by adding --source winget to search/install/upgrade. (Or by removing the Microsoft Store source, via winget source remove msstore. It can be restored via winget source reset).

[derkrasseleo]

This is mostly because the Microsoft Store's search isn't good (#1523 is the right issue, I believe).

You can bypass it by adding --source winget to search/install/upgrade. (Or by removing the Microsoft Store source, via winget source remove msstore. It can be restored via winget source reset).

That worked for me. I still think choosing which package you want to select should be much easier (for example, letting the user choose a number corresponding with the packages found)

edit: the possibility of getting different outputs with the same input is also a problem imo

[Jaifroid]

Installing by moniker and installing by product ID are now completely broken! This is not a good situation. Do I have to find ways to alert users that they must add -s winget at the end of every command, and how clunky is that for the average user? Please see various scenarios I tried below to see how completely broken this now is. Until not long ago, I could advertise how easy it is to install the Electron version of my app with winget install kiwix-electron. Now I'd say 99% of users will not be able to find a way to install, because even specifying the product ID (which should be unique) is now broken. @denelon I now think this is pretty urgent to address!

[Masamune3210]

Issue is already well known and is being worked on behind the scenes. For now either just remove the msstore source or add --id to the install command and specify the exact id, kiwix.kiwixJS.electron in this case

[Jaifroid]

@Masamune3210 If it's well known, then it should have an issue here tracking it and explaining the proposed fix. As recently as end of September, monikers were working perfectly for show and install. It's not great for devs who invest time in creating and maintaining their manifests on the repo that the end-user experience keeps changing. New versions of winget shouldn't be released without testing that they don't break existing functionality, and if existing functionality must be broken, then instructions should be provided in the app for end users to know what to do. Sure, I know to add -s winget or to use the --id switch, but for end users to be sent round in infuriating circles like this when it worked differently a couple of weeks ago is not easy to justify.

I've had to spend time this afternoon updating the install instructions in places where I'd advertised that the app could be installed with a simple winget install kiwix for the base app, or winget install kiwix-electron for the Electron version, and so on for my other related apps.

[Masamune3210]

The fix is in the backend, nothing to fix on public-facing code, and has been mentioned in the countless issues mimicking the issue of failed or improper search results. Yes, it could be communicated better but it has been mentioned multiple times in multiple issues. One of the main issues explaining the issue and that the devs are aware and are working on a fix is even mentioned in this exact thread. You cant fix people not searching before they complain. This project is still really new and is not completely set in stone yet so issues due to shifts are a thing

[denelon]

Duplicate of #1523

We're working on several issues related to the "msstore" source:
https://github.com/microsoft/winget-cli/issues?q=is%3Aissue+is%3Aopen+label%3Amsstore

[ghost]

@leochras we've identified this Issue as a duplicate of another one that already exists. This specific instance is being closed in favor of tracking the concern over on the referenced Issue. Thanks for your report! Be sure to add your 👍 to the other issue to help raise the priority.