Implement export WinGetPackage DSC resource#5074
Implement export WinGetPackage DSC resource#5074Gijsreyn wants to merge 1 commit intomicrosoft:masterfrom
Conversation
|
@Gijsreyn what does the output look like for export. I want to make sure we have parity in the resource to be able to use "set" on the same output so logically (assuming there are no dependencies/conflicts), the resource can install those packages. |
|
@denelon here you have an example output: |
If you use |
|
Does it return an array of all packages? We have a command for generating a configuration file from the current state of the device: The current "export" / "import" format would still be supported, but I'd like to make the command smart enough that it could do either the packages.json format or the WinGet Configuration YAML format over the fullness of time. |
|
Thanks for both replies. Yes it indeed returns an array of all packages. I knew about the experimental feature; currently, it is YAML, if I'm not mistaken. It doesn't fully follow the DSC schematics. However, if the command does it with the V3 schema (which is also in experimental?) in the future, this PR becomes obsolete. |
|
We're adding experimental support to leverage DSC v3 for configuration (WinGet will also support the current configuration schema). We're planning to make WinGet a DSC v3 resource so we can use that to get/set/test/export. With the new experimental feature enabled at that point, we should be closer to where we want to be. |
|
How would you envision the work in this PR being used. I just want to make sure we're not confusing folks with all the different mechanisms :) As long as we have good guidance and the right use cases, I'm fine with adding export to the current Microsoft.WinGet.DSC resource, but I want to move intentionally :) |
|
Got it Demitrius. I was just filling the gap between winget-dsc and the one in this repository. Since I do note that it would be helpful to provide guidance for users. |
|
I understand. My main concern is that if someone were to run the following command, they would subsequently be able to run
|
|
Mhm... I get your point, Demitrius. I have a strong feeling that there is an underlying question hidden here. Executing the above command will not really work because the properties within the DSC resource are different unless they can be added to the command call itself. Nevertheless, the output of a DSC resource will not follow the schematics defined in WinGet. Now, I'm considering solutions to bridge the gap between WinGet and DSC. It would easily be solvable by providing a static method that converts it to a JSON string, expecting the format WinGet expects. Maybe a talk with Steve and Mikey would be worth a shot to discuss the options? |
|
Yeah, we're actively in discussions around how we're going to support both DSC v2 resources as well as DSC v3 resources, and how the WinGet Configuration Export is going to behave. |
| { | ||
| $packages = Get-WingetPackage | ||
| $out = [List[WinGetPackage]]::new() | ||
| foreach ($package in $packages) |
There was a problem hiding this comment.
For our existing export CLI command, we only export packages that we can install later. This would require filtering the packages to those that have an available version. While we could do that in the DSC, I think it would be better to add a filter parameter to Get-WingetPackage for that purpose.
There was a problem hiding this comment.
What filter parameter are you thinking about?
There was a problem hiding this comment.
Something like Get-WingetPackage -Export, but there might be a more idiomatic name for such a parameter. It would filter to only the packages that have an available version.
There was a problem hiding this comment.
Perhaps a new cmdlet Export-WinGetPackage would also fit the use case...
There was a problem hiding this comment.
We already have Export-WinGetPackage in the WinGet Client module that behaves logically the same as winget download <package>.
There was a problem hiding this comment.
Interesting. Is there something that needs to be changed in this PR, or is it better to abandon it with all the possibilities already flying around?



Adds the export method on
WinGetPackageclass, just like some other resources in the winget-dsc repository.Microsoft Reviewers: Open in CodeFlow