You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
It is difficult to get the app I want if they have the same / similar names. #301
When a query matches more than one package, winget install (and upgrade / uninstall / show) prints "Multiple packages found matching input criteria. Please refine the input." and exits. The user then has to re-read the table, copy an exact Id or Name, add --id/--exact, and run the command again.
This is a frequent friction point when package names are subsets or near-duplicates of one another — for example Microsoft.PowerShell vs Microsoft.PowerShell-Preview, a stable vs a pre-release entry, x86 vs x64, or the same package present in more than one source.
Problem
-e/--exact and --id resolve it but are not discoverable, and even an "exact" query can still return multiple rows (pre-release variants, multiple sources).
There is no way to pick from the list that was just displayed — the command errors and exits.
Proposed behavior
Interactive numbered selection. When multiple packages match, present a numbered list and prompt the user to choose (apt/yay-style):
Multiple packages matched your query. Select one:
[1] Windows Terminal Microsoft.WindowsTerminal
[2] Windows Terminal Preview Microsoft.WindowsTerminal.Preview
Honor --disable-interactivity (and non-interactive contexts) by keeping today's refine-and-exit behavior for scripts.
Auto-select on an unambiguous exact match. If exactly one candidate exactly matches the provided Id, Name, or Moniker, proceed without prompting.
Clearer non-interactive guidance. When interactivity is disabled, the "refine" message should show the precise --id … --exact (and --source when the ambiguity is cross-source) needed to disambiguate.
Scope
Scoped to the UX of choosing among legitimately-multiple matches. Incorrect matching/correlation (the engine selecting the wrong package, or ARP correlation issues) is tracked separately.
I'd take a peak at linux package managers and see how they address it, they've been handling this exact problem from the beginning and it's been a non-issue.
Java in particular is a tricky area for any package manager. There are many different providers for JREs and JDKs. If there was only one package with the name, tag, or moniker for Java the Windows Package Manager would be able to install it.
One example is winget install vscode. Only one package has that moniker so in that case, the correct package would be installed.
C:\Users\me>winget upgrade -e Python.Python.3
Multiple installed packages found matching input criteria. Please refine the input.
Name Id
-------------------------------------------------------------
Python 3 Python.Python.3
Python 2.7.18 (64-bit) {A5F504DF-2ED9-4A2D-A2F3-9D2750DD42D6}
C:\Users\me>winget show -e Python.Python.3
Found Python 3 [Python.Python.3]
Version: 3.9.7150.0
Publisher: Python Software Foundation
Author: Python Software Foundation
Moniker: python3
Description: Python is a programming language that lets you work more quickly and integrate your systems more effectively.
Homepage: https://www.python.org
License: PSF LICENSE AGREEMENT FOR PYTHON
License Url: https://docs.python.org/3/license.html
Installer:
Type: Burn
Locale: en-US
Download Url: https://www.python.org/ftp/python/3.9.7/python-3.9.7-amd64.exe
SHA256: 3f63f4c77a6da13f9bae715eb6644a48bd5f900601e0f1f233862e8ca1a96dd8
C:\Users\me>winget upgrade --id Python.Python.3 -e
Multiple installed packages found matching input criteria. Please refine the input.
Name Id
-------------------------------------------------------------
Python 3 Python.Python.3
Python 2.7.18 (64-bit) {A5F504DF-2ED9-4A2D-A2F3-9D2750DD42D6}
Why on Earth is it even matching "Python 2" with "Python 3"?!
winget upgrade --Id Microsoft.ASPNetCore.5-x64 --exact --source winget --silent:
Se encontraron varios paquetes instalados que coinciden con los criterios de entrada. Por favor, vuelve a ajustar la búsqueda.
Nombre Id
---------------------------------------------------------------------------------------
Microsoft ASP.NET Core - Shared Framework (x64) Microsoft.ASPNetCore.5-x64
Microsoft ASP.NET Core 3.1.16- Shared Framework {f316ce75-c233-4afb-a6e8-2dd7fe72cb8e}
Activity
Antidote commentedon May 22, 2020
I'd take a peak at linux package managers and see how they address it, they've been handling this exact problem from the beginning and it's been a non-issue.
AdilHindistan commentedon May 23, 2020
Right, this's the same issue I reported
SubhamK108 commentedon Jun 3, 2020
At the moment, when installing apps with multiple search results, the following nomenclature is working perfectly:
winget install --name <appName> -eNote that the appName is Case Sensitive !
NLstn commentedon Jun 10, 2020
I also ran into this issue, i think if there is an exact match, winget should take this package and install it
stevenbrix commentedon May 6, 2021
not only is it hard to install, there is no help from winget at all. a very simple example is trying to install Java.
denelon commentedon May 6, 2021
Java in particular is a tricky area for any package manager. There are many different providers for JREs and JDKs. If there was only one package with the name, tag, or moniker for Java the Windows Package Manager would be able to install it.
One example is
winget install vscode. Only one package has that moniker so in that case, the correct package would be installed.robross0606 commentedon Sep 11, 2021
Here's another example for
upgradecommand:Why on Earth is it even matching "Python 2" with "Python 3"?!
edgarchinchilla commentedon Sep 13, 2021
Here is another example, only to add test-cases:
derkrasseleo commentedon Oct 11, 2021
I would like to choose between the packages winget finds by inputting a number, for example. yay handles this perfectly imo
unilock commentedon Oct 21, 2021
Yet another example, in which
--exactdoesn't work.EDIT: The ID can't be in quotation marks, apparently. Might be worthwhile to document that somewhere.
EDIT2: At least, that was the case for
OpenJS.NodeJS.LTS. Doesn't help here, it seems.