WinGet configuration Preview

[Guest Demitrius Nelon]

The Windows Package Manager team has been working on several things we’re sure you will be very excited about.

 

If you’ve been following the WinGet blogs, you’re already familiar with package management on Windows. We’ve got some goodies in store for you like package pinning, our new PowerShell module, and running WinGet in the system context. We’ve gotten lots of feedback on how WinGet has been a game changer in terms of time saved, convenience, and simplification when setting up a new Windows PC. WinGet configuration takes things to the next level!

 

[HEADING=1]WinGet configuration[/HEADING]

 

Save time and skip the manual effort of setting up a new machine or onboarding a new project by using this unattended, reliable, and repeatable mechanism.

 

Remove the worry of searching for the right version of software, packages, tools and frameworks to download or settings to apply. WinGet configuration reduces this manual and error-prone process down to a single command with a WinGet configuration file. Just run [iCODE]winget configure <WinGet configuration file>[/iCODE] in the command prompt and when it’s done, you are ready to code!

 

WinGet configuration was built on top of PowerShell DSC. It’s using a declarative YAML file that describes what the environment “looks like” when it’s configured. The file defines the environment in terms of DSC resources that can test the current state of the system and apply the necessary changes.

 

If you want to try this with WinGet, you will need to install one of our preview releases and enable the experimental feature. Learn more about WinGet configuration at Microsoft Learn. You can also try this functionality out in Dev Home. We’ve provided several sample configurations in the Dev Home project at GitHub.

 

[HEADING=1]WinGet PowerShell modules[/HEADING]

 

Many of you have been asking about when a native PowerShell module would be available for WinGet. The text-based output from WinGet isn’t easy to parse, and that makes it much harder to use in scripts. The first “prerelease” module was shipped near the end of April 2023, and we published an update on May 12th.

 

Note: The module is not listed as “Prelease”, but it should be treated as such. The version published on May 12th is 0.2.0 and the Microsoft.WinGet.DSC module depends on Microsoft.WinGet.Client so it couldn’t be published as “Prerelease”. If you are comfortable with using a preview version:

 

Open up PowerShell (I like to use Windows Terminal and PowerShell 7) and run [iCODE]Install-Module Microsoft.WinGet.Client[/iCODE].

 

 

The magic of WinGet configuration is powered by PowerShell DSC (Desired State Configuration). The Microsoft.WinGet.DSC module allows you to configure your WinGet settings and preferences. It also enables you to install WinGet packages using [iCODE]Invoke-DSCResource[/iCODE].

 

We’re also working on Microsoft.WinGet.Source to manage WinGet REST sources, and Microsoft.WinGet.Create to generate manifests for packages. Once these have all been published to the PowerShell Gallery, we will wrap them up in the Microsoft.WinGet module so you get all the goodness with a single install.

 

Some of the cmdlets require PowerShell 7, but we’ve enabled enough functionality to allow you to use Windows PowerShell to install, repair, or upgrade WinGet so you can then [iCODE]Install-WinGetPackage Microsoft.PowerShell[/iCODE] and then take full advantage of WinGet configuration.

 

[HEADING=1]WinGet pinning[/HEADING]

 

Sometimes you don’t want WinGet to upgrade certain applications. If you’ve ever run [iCODE]winget upgrade --all[/iCODE] and it upgraded something you didn’t want, you were forced to manually downgrade it afterwards. From that point on you have to remember this tedious process, or you gave up on the convenience of being able to use a single command. Packages may introduce breaking changes that you may not want to integrate into your workflow quite yet. Packages may update themselves and you prefer that experience. You may want to maintain some of the packages through other channels outside of WinGet, or you prefer one source over others within WinGet. You might also want some of the packages to stay in some major version but allow minor version changes during upgrade.

 

To achieve goals listed above, WinGet pinning supports three types of Package Pinning:

 

• Blocking: The package is blocked from [iCODE]winget upgrade --all[/iCODE] or [iCODE]winget upgrade <WinGet package>[/iCODE], you will have to unblock the package to let WinGet perform an upgrade.
  
• Pinning: The package is excluded from [iCODE]winget upgrade --all[/iCODE] but allows [iCODE]winget upgrade <WinGet package>[/iCODE], a new argument “–include-pinned” will be introduced to let [iCODE]winget upgrade --all[/iCODE] include pinned packages.
  
• Gating: The package is pinned to specific version(s). For example, if a package is pinned to version 1.2.*, any version between 1.2.0 to 1.2.x is considered valid. To allow user override, “–force” can be used with [iCODE]winget upgrade <WinGet package>[/iCODE] to override some of the pinning created above.
  

 

The post WinGet configuration Preview appeared first on Windows Command Line.

 

Continue reading...