winget configure and its place within the product #3346
Replies: 4 comments 5 replies
-
This is the first preview. We have a lot of work to do here. The vision is to have the full capabilities of "Configuration as Code". Yes, the only "defined" variable is the WinGetConfigRoot today. WinGet import already handles installing a bunch of things, but there were clearly gaps on getting the rest of the configuration to work. As there is no LCM (Local Configuration Manager) on Windows desktop and at times users need to switch versions of dependencies, we decided to have WinGet act as an LCM with a declarative configuration file and to leverage PowerShell DSC to get the work done. |
Beta Was this translation helpful? Give feedback.
-
I'll work on creating some separate issues for what you're seeing so we can track the fixes/changes needed and create Issues for the additional work that needs to be done at a more granular level. Thanks for taking the time to provide such detailed feedback! |
Beta Was this translation helpful? Give feedback.
-
I created a couple of issues. |
Beta Was this translation helpful? Give feedback.
-
I wanted to touch on some of this as well. On paper It was also quite unclear that DevHome's machine configuration was essentially the same thing as winget configure, and given the types of github issues I've seen that cross-reference each repo, I suspect there's probably more room for bringing the two features together a bit more as there seems to be some duplicated effort going on. (For example microsoft/devhome#912 ) A lot of the winget DSC stuff was pretty confusing just because some of it was talking about using DSC to install winget, and the other half was talking about invoking DSC from within winget. And honestly it took a while to figure out that was largely what winget configure was doing. It would also probably be worth the effort to spend a day going through almost every public winget configuration piece of info and really do a cleanup pass on it. Like for example a lot of the documentation references using My predominant use-case is the one advertised heavily by the Dev-Home team, end-to-end machine setup. I will likely have 3 configurations, my own baseline, one for my work PC's, and one for my home PC's, then maybe some per device type, like for my laptops.
|
Beta Was this translation helpful? Give feedback.
-
How does
winget configure
fit into the overall product - i just started authoring some configurations and i honestly have no idea what to think. Is the DSC YAML supposed to be the new home for DSC configs, will it stop at being a lightweight DSC intro?I've had some pain points trying to do some basic dev machine setup here - most of these fail because some basic dsc resources fail or are just not supported from PSCore.
WSL Enabling fails because apparently
winget configure
runspwsh.exe
which cannot run PS Code regarding windows optional feature management.Copying files using the
File
resource fails because apparently it needs windows management dlls which cannot be loaded in ps core also.So i tried writing the copying via
Script
resource - lo and behold - it is painful:What im seeing is there seems to be no way to have variables except some well known variables like
${WinGetConfigRoot}
that are documented nowhere so i have do guess that ${UserProfile} isnt available.Alot of this feels like a super reduced subset of DSC in itself which seems to crumble once it goes one inch beyond winget package install - so why are we introducing a new DSL when there is powershell for DSC and a PS-based DSL already. All samples provided in the various repos updated during build are basically winget and VSPackage only - why not import a app id / source moniker combo list from a file and call it a day?
Where does microsoft see this feature in the future?
Beta Was this translation helpful? Give feedback.
All reactions