winget install -m should support URI paths also

[chrpai]

Description of the new feature/enhancement

Add support for HTTP/HTTPS urls to winget install -m [path] option.

This would allow for light weight sharing of YAML files without having to create a new source and register it. This would be useful for sharing one line commands to users to install software not in yes merged in the repos. For example buddy testing.

Proposed technical implementation details (optional)

[megamorf]

I don't really see any benefit in this over pulling the file ahead of the installation, e.g.:

Invoke-WebRequest -Uri https://github.com/microsoft/winget-pkgs/raw/master/manifests/Git/Git/2.24.1.2.yaml -OutFile git.yaml
winget install -m git.yaml

[chrpai]

I work on a team that will often run ps remote commands on a pool (thousands) of machines and anytime you have to touch the local disk it gets more complicated. Not having to figure out a temp directory, download a file and clean up the file is simpler and more reliable.

winget install -m https://github.com/microsoft/winget-pkgs/raw/master/manifests/Git/Git/2.24.1.2.yaml

^^ Is cleaner

[megamorf]

Sorry, but we're talking about a text file that is at most a few KB in size. And you can even do:

Invoke-WebRequest -Uri https://github.com/microsoft/winget-pkgs/raw/master/manifests/Git/Git/2.24.1.2.yaml -OutFile $env:temp\git.yaml
winget install -m $env:temp\git.yaml

That uses the user's temp directory so that the file gets removed on the next cleanmgr run. I personally don't see the need for this but I'm very much interested in what other users think about the request :-)

[WingsLikeEagles]

I think it's a good idea. Behind the scenes it could just call Invoke-WebRequest and pull the file to a temp directory. I mean even if you did implement this, doing a winget install -m https://github.com/microsoft/winget-pkgs/.... is going to download the yaml file to a temp directory before running it. You just may not see it. Unless you have some slick way of running the yaml as it comes in... but that seems unreliable.

[denelon]

We have now have a group policy to restrict the ability to use "local manifests". I'd like to keep this intent so it can be managed by policy and doesn't introduce a potential risk. The new REST API allows an enterprise to stand up a private repository for this use case. Enterprises can then manage what packages are available and where they install from.

We've been discussing a new source type that could be based on a UNC path or something similar, but we haven't reasoned through all of the scenarios related to "search", "list", "upgrade", "export", etc.

I believe a network share to a YAML manifest would still work with "-m". I haven't tested to confirm. Feel free to correct me if that is not the case.

[WardenHub]

For those potentially reading this, a network share to a yaml manifest works (just tested this).

I found this while looking into setting up a rest api / using github to share the manifests