PowerShell cmdlet for: winget download <package>

[denelon]

Description of the new feature / enhancement

I want a PowerShell cmdlet that is essentially the same thing as winget download.

This command in the CLI downloads a manifest and an installer.

Note:
The manifest generated by this command points to the actual installer URL on the Internet and does not include references to the other installers in the original manifest provided by the WinGet source.

---

We're leaning towards Export-WinGetPackage as the name of the cmdlet.

We would not plan to implement an Import-WinGetPackage because WinGet uses the InstallerUrl field to determine where the installer should be downloaded from.

Additional Context

Unfortunately, this causes a bit of an impedence for the existing winget export and winget import commands. The current thinking is that we would not implement winget export in a PowerShell cmdlet as it is implemented today in the CLI. We have been considering other cmdlets for that scenario. Maybe something like:

• Export-WinGetPackageList
• Export-WinGetPackageSet

We're also considering making the current packages.json schema format deprecated in favor of the WinGet Configuration schema format. A new cmdlet like:

• Import-WinGetPackageList
• Import-WinGetPackageSet
  The Import-WinGetPackage*Foo* cmdlet would accept either the packages.json or the WinGet Configuration to provide the functionality for installing the packages, but not applying other units of configuration in a WinGet Configuration file.

We're looking at the issue below to address exporting the current configuration of a device with something like Export-WinGetConfiguration. The Invoke-WinGetConfiguration and Start-WinGetConfiguration cmdlets are used to apply the desired state specified in a WinGet Configuration file to the device.

• Generate configuration from machine state  #3274

Proposed technical implementation details

No response

[jlcummings]

My immediate reaction is that the name currently proposed would lead to utter confusion based on described intent.

I would suggest that 'Save-WingetPackage' would be more inline with the overall approved-verb list intent for downloading a package without installing it immediately, as well as align with the OneGet and now AnyPackage provider docs for AnyPackage: Save-Package. OneGet and apparently now AnyPackage are the underlying machinery of Powershell's Package Management umbrella. This would allow import and export to remain available for coinciding functions.

[denelon]

I think "Save-WinGetPackage" does make sense. @ryfu-msft what are your thoughts here?

[denelon]

I've had discussions with several folks on this particular scenario.

TLDR; The cmdlet will be "Export-WinGetPackage".

One of the primary use cases we're thinking here is we will have customers who wish to stand up a private source for WinGet packages. When this is the case, some of them would like to use the "winget" source as an "upstream" to capture package installers and manifests so they can "publish" them to their own REST source.

---

In the context of the WinGet CLI command structure vs. the PowerShell cmdlet structure the following paradigm was used to influence our thinking:

Note: There would be no corrolary "Import-WinGetPackage" in the short term, as we use Install-WinGetPackage.

WinGet Client
  Microsof.WinGet.Client PowerShell cmdlet

winget download
  Export-WinGetPackage

---

In the context of the above scenario, this pattern would be used to "get a package" from one source for subsequent publishing to a different source:

---

PowerShell Module
  PowerShell Cmdlet

Microsoft.WinGet.Client
  Export-WinGetPackage

Microsoft.WinGet.Source
  Publish-WinGetPackage

In the context of the "Publish-WinGetPackage" we're thinking the "Unpublish-WinGetPackage" would logically be used to remove a package from a WinGet Source.

---

Other Considerations:

• I also like "Save-WinGetPackage" so I'm totally OK with having an alias such that "Save-WinGetPackage" actually runs "Export-WinGetPackage". This way users have a choice.
• For the same reason above, we may implement an "Import-WinGetPackage" as an equivalent for the WinGet CLI winget install -m <path to manifest>