Repository navigation
Packages with the same ID and name in multiple repos break "winget show" and "winget install" #840
Description
Brief description of your issue
Packages with the same ID and name in multiple repos break winget show and winget install
Steps to reproduce
- Add more than one repo to winget somehow (for example, the msstore repo that you can add via experimental).
- run
winget show --exact --id Microsoft.WindowsTerminal - Become confused when even though you passed
--exact --id, there are still two results.
Expected behavior
WinGet should put the different repos in the returned table, and say "This package exists in multiple repos, specify which you want to show/install from with --source ".
Alternatively, it should just pick whichever one has the highest version (or the user's specified version if they pass -v), which is what other package managers do when faced with this problem (this probably makes a bit more sense in the long run, given that one of the major reasons people add additional repositories is to get access to newer versions of software that aren't ready for public consumption, like canary versions of browsers).
Actual behavior
WinGet tells me it found multiple results, but doesn't tell me why (since there are no repos in the table), making it extremely difficult to figure out why I can't install Windows Terminal.
PS C:\Users\Easton Pillay\projects\winget-pkgs> winget install Microsoft.WindowsTerminal
Multiple packages found matching input criteria. Please refine the input.
Name Id
------------------------------------------
Windows Terminal Microsoft.WindowsTerminal
Windows Terminal Microsoft.WindowsTerminal
PS C:\Users\Easton Pillay\projects\winget-pkgs> winget install --exact --id Microsoft.WindowsTerminal
Multiple packages found matching input criteria. Please refine the input.
Name Id
------------------------------------------
Windows Terminal Microsoft.WindowsTerminal
Windows Terminal Microsoft.WindowsTerminal
PS C:\Users\Easton Pillay\projects\winget-pkgs> # Uh-oh!
Environment
PS C:\Users\Easton Pillay\projects\winget-pkgs> winget --info
Windows Package Manager v0.2.10771 Preview
Copyright (c) Microsoft Corporation. All rights reserved.
Windows: Windows.Desktop v10.0.19042.867
Package: Microsoft.DesktopAppInstaller v1.11.10771.0
Logs: %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir
Links
--------------------------------------------------------
Privacy Statement https://aka.ms/winget-privacy
License Agreement https://aka.ms/winget-license
Third Party Notices https://aka.ms/winget-3rdPartyNotice
Homepage https://aka.ms/winget
PS C:\Users\Easton Pillay\projects\winget-pkgs>
Activity
denelon commentedon Apr 1, 2021
Great catch Easton Pillay (@jedieaston). We've been thinking about adding preferences to the settings that would allow a user to specify which source should be used when there are multiple matches. I like the idea of comparing which has the latest version. One of the challenges is the store source doesn't currently expose the version.
denelon commentedon Apr 27, 2021
deadundead, this happens when there are two identical package identifiers in two different sources.
You will need to specify the source to disambiguate.
winget install Microsoft.WindowsTerminal -e -s wingetwould use the "default" source.It looks like we need to clarify the messaging, and display the sources in this case.
spragginsdesigns commentedon Oct 16, 2021
This is literally happening to me right now. Look at this screenshot:
tardis4500 commentedon Oct 19, 2021
I don't think this is just a documentation issue. Consider the following:
remontees commentedon Dec 16, 2021
I experienced the same issue installing Oracle.JDK.17
Trenly commentedon Jun 16, 2023
[Policy] Area-Matching
denelon commentedon Jul 27, 2026
This has been resolved. When the same package ID is present in multiple sources,
winget install/winget shownow surface the Source in the disambiguation output, so you can tell the matches apart and pick one with--source:That addresses the original problem - the old table had no Source column, which made it impossible to understand why the input was ambiguous.
There's also a source priority capability (experimental
SourcePriorityfeature): when matches span sources of differing priority, WinGet narrows to the highest-priority source automatically and lets you know it did - close to the "just pick one" alternative suggested here.Closing as resolved. If you'd like WinGet to instead auto-select by highest version across sources (rather than by source priority), please open a new feature request describing that behavior.
(Drafted with GitHub Copilot assistance.)