WinGet configure

[crutkas]

Description of the new feature / enhancement

As I developer I want an automated configuration for my project so it's easier for developers to contribute.

PowerToys has a nuanced configuration required to help developers succeed when contributing new features or bug fixes. WinGet can install the tools we need, but there are some configuration parts that are missing and we need a smidge more.

I want to be able to winget configure <configuration file> or winget configure <URL to configuration file>so I can build an automated setup process and make anyone that wants to build / contribute back to PowerToys the easiest process possible.

After the process has completed, users can simply open the solution and [F5] in Visual Studio to build the solution / installer / installer installs PowerToys

Proposed technical implementation details

1. Read a configuration file.
2. Apply the configuration to my local environment.

[denelon]

@crutkas

Thank you for creating the Issue. We've been discussing some things internally as a part of our findings related to:

• #2697

We've also been working on:

• #221

As we've been working with the PowerShell team during the implementation of the WinGet DSC resources to provide a way to get WinGet delivered as a part of "App Installer" without the dependency of the Microsoft Store, we've also been thinking about configuration management. Some of our engineers have been doing further exploration.

Note: The DSC work may also be a way to begin support for Windows Server and Windows LTCS editions. We still have work to enable WinGet to "upgrade" itself with the absence of the Microsoft Store. We still have work to understand the implications of Windows Server without the Desktop experience.

We have been working on a declarative configuration file and ways to apply a configuration to the local system. It would help address the lack of pre-install and post-install actions in WinGet. As a consistent part of our approach to package management, we would want the same kind of behavior for configuration management:

1. Read a "declarative" configuration file
2. Validate the configuration file syntax
3. Build the dependency graph
4. Load the necessary PowerShell DSC resources
5. Apply the configuration (Invoke-DscResource)

[denelon]

@SteveL-MSFT,

I shared the work we have in progress with the PowerShell DSC Community:

• #2697

We're planning to present a demo at their next community call.

For the work on this Issue, we would love to continue collaborating with you and the PowerShell team.

[MorNando]

@crutkas

Thank you for creating the Issue. We've been discussing some things internally as a part of our findings related to:

• #2697

We've also been working on:

• #221

As we've been working with the PowerShell team during the implementation of the WinGet DSC resources to provide a way to get WinGet delivered as a part of "App Installer" without the dependency of the Microsoft Store, we've also been thinking about configuration management. Some of our engineers have been doing further exploration.

Note: The DSC work may also be a way to begin support for Windows Server and Windows LTCS editions. We still have work to enable WinGet to "upgrade" itself with the absence of the Microsoft Store. We still have work to understand the implications of Windows Server without the Desktop experience.

We have been working on a declarative configuration file and ways to apply a configuration to the local system. It would help address the lack of pre-install and post-install actions in WinGet. As a consistent part of our approach to package management, we would want the same kind of behavior for configuration management:

1. Read a "declarative" configuration file

2. Validate the configuration file syntax

3. Build the dependency graph

4. Load the necessary PowerShell DSC resources

5. Apply the configuration (Invoke-DscResource)

Thanks, WinGet certainly has potential. I would LOVE to have the option to do post configuration on a WinGet package with both PowerShell DSC and normal PowerShell. That second one is crucial for me since I don't always want to use DSC configuration. Do you know if that is in the works? It would be a game changer in my mind and would replace the need to use Chocolatey.

[denelon]

WinGet as a package manager won't do post-configuration, but as a configuration manager, you can leverage Invoke-DscResource and get the full power of both. The Microsoft.WinGet.DSC module was built for this scenario.

It's a bit clunky, but you can use Windows PowerShell and Microsoft.WinGet.Client to install PowerShell 7 to get the full capabilities.

[thilojaeggi]

Seeing as this is the "founding" issue for winget configure I think it's best to ask my question here.

As of now it seems the winget configure command only takes local configuration files or those directly accessed via a web source like from a GitHub repo.

Is there any implementation planned for supporting rest sources (json support) or no?

Of course the rest source could also just return dynamically generated yaml.

[denelon]

@thilojaeggi we've got:

• https://github.com/microsoft/winget-cli/issues/3554

I don't think we have any plans to add a configuration file to https://github.com/microsoft/winget-cli-restsource at this point in time. We're still discussing possibilities with some internal teams to see what might make sense.

[denelon]

WinGet configure will be stable in WinGet 1.6. The release candidate just went out today.