-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Start Microsoft.WinGet.Configuration module #3187
Start Microsoft.WinGet.Configuration module #3187
Conversation
This comment has been minimized.
This comment has been minimized.
/// Invoke-WinGetConfiguration. | ||
/// Start configuration and waits for completion. | ||
/// </summary> | ||
[Cmdlet(VerbsLifecycle.Invoke, "WinGetConfiguration")] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would really suggest starting with Start
and Complete
so that you don't do things you have to untangle by only implementing Invoke
.
[Parameter( | ||
Mandatory = true, | ||
ValueFromPipelineByPropertyName = true)] | ||
public string File { get; set; } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There should be a Get-WinGetConfiguration
command that is the primary method to open a file and other commands should be taking in a file path only as a convenience. Given that there might be an arbitrary number of mechanisms to load a configuration set, maybe we even force it to be loaded with the Get
.
About a week ago I stumbled on the Are you looking for feedback on this |
@g0t4 yes, we're always looking for feedback. Package Management is complex to begin with, and adding configuration management is probably an order of magnitude more complex. Feel free to create issues or discussions. We're always looking for user scenarios that either aren't covered, or where the behavior isn't quite right. |
This PR sets the foundation for the new PowerShell module Microsoft.WinGet.Configuration which is going to be an equivalent of
winget configure
The module is going to be built as a binary module and it supports using its own ACL to load dependencies. The Microsoft.WinGet.Configuration.Cmdlets project will contain all the cmdlet entry points and Microsoft.WinGet.Configuration.Engine the actual logic.
This module consumes Microsoft.Management.Configuration which uses cswinrt and requires being run on an MTA. This is achieved via MtaCommand.cs. This class contains functions that will verify if the current thread is already running on an MTA (via pwsh.exe -MTA) and if not start a new MTA thread. Every command that consumes winrt objects must implement it.
MtaCommand.cs also implements methods to handle waiting for asynchronous calls and allows sending messages to the PowerShell host that are required to be executed in the main thread (only WriteDebug is implemented for now, but any other method follows the same approach). This is based on the async mechanism that azure-powershell uses.
This PR includes
Invoke-WinGetConfiguration
but is just a proof-of-concept cmdlet and should not be taken seriously.The next PR will be all the changes in the configuration processor to enable
ConfigurationProcessorType.Default
Microsoft Reviewers: Open in CodeFlow