Proposal: `winget run`, a way to run a package's canonical executable that winget-cli controls

Description of the new feature / enhancement

Many winget installations don't automatically add to path, so many programs that people expect to immediately be able to run from the cli after installing (especially with -h) are Not Found.

I think this creates a disconnect from most people's expectations for a package manager; and independently of opinion about intuition from folks coming from the linux (or choco) world, adds a hit to the productivity of winget users.

It is understandably hard to corral every MSI maintainer into enabling/adding Add To PATH functionality, especially for GUI applications; so maybe ideally, a solution to this just doesn't even try that.

Precedent: npx

npm's npx is sort of this idea, but takes it a bit further than I'm thinking: it wraps and sandboxes the entire install -g process and runs a CLI tool on-the-fly.

Interface

PS > winget install -h Vim.Vim
PS > vim

The term 'vim' is not recognized as a name of a cmdlet, function, script file, or executable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

PS > winget run vim

* vim opens*

Precedence system

Proposed technical implementation details

My understanding of winget install is that when installing, it has an order of precedence for resolving a package identifier, detailed in:

https://github.com/microsoft/winget-cli/blob/master/src/AppInstallerCLICore/Commands/InstallCommand.cpp#L62
https://github.com/microsoft/winget-cli/blob/master/src/AppInstallerCLICore/Workflows/CompletionFlow.cpp#L124
.

The same system could be used for resolving the target package of winget run.

I'm not as knowledgeable about the concept of the "primary executable" of an MSI, given there can be many executables in the output directory, and it may be somewhat of a nebulous concept (especially when some packages install .exes with name-version-date.exe, others may install a "dx9, dx11, dx12", some may install an "avx2, sse4", some may install an "x86, x64", etc. Stores like Steam or GOG galaxy implement something like this, where they differentiate between games that have a single executable, a dx9/11/12 executable, or a separate config.exe that runs before a game (See: Nihon Falcom's Ys, or Trails of Cold Steel).

Maybe:

• above all, a new installer manifest yml variable, Installers.Installer.RunExecutablePath takes precedence. This would be the only allowed system for winget run --silent, for CLI stability/security and as a "carrot" for admins who want to implement winget at scale, i.e. in CI systems or cloud userdata scripts. Even though it's still manual, it provides a direct and central location winget-pkgs for this, rather than having to reach out to every package maintainer in every repository individually

• list executable files in a directory.

• filter remove names "install", "uninstall".

• if the end result is a single executable, run that.

• if not confident (two executables), and allow user to choose from a list, and set it permanently in their AppData.

Sorry if this proposal sounds silly!

Start with the referenced precedence logic in src/AppInstallerCLICore/Commands/InstallCommand.cpp and src/AppInstallerCLICore/Workflows/CompletionFlow.cpp. Review how a new winget run command and the proposed Installers.Installer.RunExecutablePath manifest field would fit that resolution flow. Done should include a defined executable-selection behavior and the demonstrated command working after installation.