Document the behavior of monikers and search prioritization

[jedieaston]

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.

Originally posted by @Jaifroid in https://github.com/microsoft/winget-cli/issues/1523#issuecomment-956749936

I'm just breaking this out into a separate issue because I'm interested in the full answer too.

IMO, counter to the current logic, I think the prioritization should be ID -> Moniker -> Name. I would expect a user to most likely know dotnet-runtime, followed by Microsoft.dotnet.5.x64, followed by ".NET 5 Desktop Runtime NT (64-bit) (for legacy PCs)" or whatever the ARP name is. Of course, the PackageName business will be cleared up with v1.1, but you understand my meaning. (The ID should go first just to be able to disambiguate quickly, even though most users do not know it).

I also do not think that we as users should have to prioritize the sources by hand. That's not how APT or yum do it, (they just take the highest version number), that's not how npm does it (it makes you namespace your sources if you want to select between them), and I think that will be really confusing to control for both users and administrators.

(These are just my opinions. There's probably problems with this.)

[jedieaston]

This is related to #1663, if they are too similar feel free to close this one :)

[denelon]

I'll describe the behavior as of Windows Package Manager 1.1 (keeping the version here for future visitors as this will likely change in the coming months).

Much of this depends on which flags are present, but I will just focus on the "install" flow with no additional options configured, as it seems to have the most open questions.

When a user runs winget install foo, the client is attempting to find a single best match. If "foo" matches only one package with "foo" of either "Id", "Name", or "Moniker" (case insensitive), then that package is selected.

When multiple sources are configured, the search query may return zero or more matches for each source. In this case, it is possible for each source to return zero or more results. When this happens, the user is asked to disambiguate.

The work item mentioned above is intended to help refine the results from multiple sources down to a single best match if possible. The user may still need to disambiguate if multiple results still remain.

[Jaifroid]

I think a lot of the problems would go away if you could establish a clear order of precedence. Like @jedieaston I would favour ID - monker - name, probably refining that as follows:

1. Exact case-insensitive match on the full ID from either store (this should always produce a single unambiguous package)
2. Exact case-insensitive match on moniker from winget repo (you should encourage unique monikers, but I recognize that cannot be guaranteed), ignoring any other matches below -- this should mostly produce a single package
3. Case-insensitive match on (future) monikers from msstore source (when they are implemented)
4. Exact match on tag
5. Partial word-level match on ID
6. Partial word-level match on name

Behaviour for winget show and winget install: If any of 1, 2, or 3 produce a unique package, in that order, just show or install it. Only if these do not produce a unique package should results from 4, 5, and 6 be displayed (together with any ambiguous results from 1, 2 or 3), with a way for the user to select one of the listed packages.

Behaviour for winget search: All matching results should be shown, but in the order they are produced from 1 to 6.