Deduplicating results from multiple sources

[denelon]

Description of the new feature / enhancement

When I run winget install powertoys I get duplicate results for the "same package".

WinGet should be able to determine if the package from more than one WinGet source is a duplicate (SHA256 for example). I should be informed there is a setting I could use to specify which source to default to when this happens.

Proposed technical implementation details

Add settings for the sequence to use when multiple sources return the "same" package (they may have different names, identifiers, and other metadata), but the installer is "unique" given the SHA256.

When WinGet detects duplicates and there are no sequences specified, the user should be informed about the feature.

When a user has settings for the sequence to be used when more than one source contains the same package, then WinGet should install the package from the preferred source (based on the sequence).

[Trenly]

• Related to Ability to select installer when multiple matches are returned. #1620 but specifically refined for sources

[denelon]

• And: [New Feature]: Customizable sorting for search output #1769

[denelon]

There may also be cases where the two sources aren't both offering the "latest" version of the package in question. In that case the SHA256 wouldn't match, so we will need to dig a bit deeper into a solution that works when this happens.

[jamrobot]

There may also be cases where the two sources aren't both offering the "latest" version of the package in question. In that case the SHA256 wouldn't match, so we will need to dig a bit deeper into a solution that works when this happens.

At this point, yes, MSStore latest version is v0.90, and WinGet is v0.89. And due to some issue in WinGet package submission process which cause the delay.
But even if the issue fixed, version mismatch will still here (MSStore v0.90 vs WinGet v0.90.1_hotfix version).
I think the right fix should be done in winget to allow user to specify preferred source if duplication found.

It is possible that version mismatch in certain period of time could be by-design.

[denelon]

For the "current" issue with PowerToys, I'd anticipate the "new" version published to WinGet would also be published to the Microsoft Store so both would have the same "latest" version available. It's almost certain there would be some delay before both sources become "eventually consistent" with having the same version available in both sources.

I've been thinking about a few different possibilities for dealing with these gaps in time where the same version isn't available in both sources. We may be able to create a record on the local device when we have a strong correlation between two package identifiers that have the "same" package so in the future, when the sources are offering different versions, WinGet can gracefully handle the situation.

In my current thinking, the "worst case" scenario is the first time a user attempts to run winget install powertoys (and the versions don't match), the user will be asked to disambiguate the way they are today. Once the package has been installed on the device, attempting an "install" (which switches to upgrade) or "upgrade" would result in the check being performed based on the source the package had been installed from.

Users could certainly use "--force" to change the source if they wanted, but in most cases, I'd expect this to be a rarely hit edge case.

[JohnMcPMS]

#6029 would solve the sub-issues if made non-experimental. Using it makes any comparison between the two packages moot as well, as the higher priority source would always be chosen. It would only need some messaging updates to be consistent with the request here.

I also think it would be wise to pair it with the work to put local filtering validations on REST responses to prevent errant search results from overeager search being treated as intent.