SHOW fails to display info for specific packages

[Kein]

Brief description of your issue

WinGet fails to show any info for specific existing packages despite having it in list

Steps to reproduce

1. winget list -q Calculator
2. winget show --id Microsoft.WindowsCalculator_8wekyb3d8bbwe

Expected behavior

The usual show info is displayed

Actual behavior

No package found matching input criteria.

Environment

Windows Package Manager v0.2.0 Preview
Windows: Windows.Desktop v10.0.19042.685

[denelon]

This is due to the package being in the msstore source.

[denelon]

What information are you looking for in this case?

[Kein]

At bare minimum the same information it provides for the currently visible packages (on which SHOW works)? Ideally I'd also want to see dependency tree. Perhaps lvl1 just for now to see immediate flat dependencies, may be a tree later down the line.

[denelon]

Dependencies haven't been implemented yet. When they are, we should be able to show the dependency graph.

[Kein]

Well, sure, but dependencies is a supplementary feature. It is still a bug that it cant find and show any info on the app it knows about from the list(???)

[chausner]

Well, sure, but dependencies is a supplementary feature. It is still a bug that it cant find and show any info on the app it knows about from the list(???)

I'd agree. If no additional information can be shown for Store apps at the moment, at least a more helpful and less confusing error message should be shown.

[yao-msft]

This is actually because Calculator app is not in the curated list of the experimental store source or the winget source. winget is not able to correlate the installed app with any app in existing sources so it shows "No package found". This should get better when we have a real store source one day or a bigger catalog in winget sources.

[denelon]

These commands work: winget show "Windows Calulator" winget show 9WZDNCRFHVN5

Any package with an associated source can now be displayed with winget show

There may still be exceptions where WinGet doesn't have the ability to match the "Id" for pre-installed packages or packages that are installed via the Microsoft Store and are not available in the "msstore" REST source.

[Kein]

Which branch/commit is this?

[denelon]

It's fairly old. I'm not sure which release this initially appeared in. My best guess is the 1.2 release where we had the Microsoft Store "msstore" source and support for REST enabled. We've had changes with winget list where we stopped displaying packages linked to the "msstore" source due to some bad match results based on the heuristics we initially implemented.

The primary gap today is related to UWP packages coming from the Microsoft Store that weren't installed via winget. The "Id" column in winget list would display with a name like "<Publisher>.<Package>_8wekyb3d8bbwe". The "msstore" REST source manifests haven't been updated to include the package family name which we would use to key to the installed package.

If the package has been installed with WinGet, then we get an "Id" like "9NBLGGH4NNS1" (this one is the App Installer). In these cases, the "msstore" source is referenced, but the lack of a version number prevents the winget upgrade --all flow from knowing if a newer version is available.

[Kein]

winget show 9MV0B5HZVK9Z
Failed when searching source; results will not be included: winget
Found Xbox [9MV0B5HZVK9Z]
Version: Unknown

Weird winget error aside, any reason it fails on version?

[denelon]

@Kein the "msstore" REST source isn't providing the version information WinGet needs for the upgrade comparison logic. It's present via the "show" command, but not the endpoint used for upgrade. They have been notified, and hopefully we'll get a fix.

[denelon]

WinGet Show now displays dependencies and other metadata from the manifest including the URL to the installer (unless the Microsoft Store "msstore" source is used for legacy UWP packages).