Add Native PowerShell Support

Description of the new feature/enhancement

A vast majority of Windows automation is done with PowerShell. To support those users create and ship a winget PowerShell module on PowerShell Gallery.

A colleague of mine sent me a link to the Windows Package Manager Preview blog article just now. The first thing I said to myself was "Why is this a command line application and not a native Powershell cmdlet?". I'm surprised any new command only software from Microsoft isn't Powershell (dotnet/core based) let alone not with Powershell out of the box.
This might just be my naivety showing through.
I'm genuinely curious as to the reasons for that, if any of the devs can provide insight?
Is it perhaps related to this being delivered via the Microsoft Store?

I've started actively working on a new PackageManagement provider that can lay over the top of WinGet. Based a quick review the CLI doesn't look too different from Chocolatey, so it shouldn't be difficult to adapt to it as a gap-filler until Microsoft puts out something official.

Edit: Initial work on the provider is complete! See below.

The one thing I dislike about chocolatey is having to deal with those string outputs of commands in automation tasks, please make it so we can work with powershell objects.

1 on this.

WInget is a great concept, badly let down by its UI. Here are my problems:

No Get-Help - existing help is thin to say the least
inconsistent command structure
No objects emitted or taken as a parameter
No Tab Completion making it harder to use
Output is string so no Get-Member to discover output - less discoverable
All in all harder to automate programmatically without having to go back to the stone age with grep/sed/.awk
Probably not based on .NET so less portable and less easy to leverage.

My view: Winget is a great product, let down by an underimagined UI. The team needs to re-read the Monad Manifesto, then come back with a better implementation.

Please add real cmdlets. Please make winget fully automatabile. Please bring back the consistency inherent with PowerShell.

How could a project like this even get started without planning for PowerShell integration? The word "PowerShell" does not appear once on the Roadmap page for this project. Is this a turf war issue between different managers or technical fellows at Microsoft?

It's fine that winget does not require PowerShell, that's not the issue. But to not have a single word about PowerShell integration as a primary design goal? Is the plan to have PowerShell parse the text output of winget be like parsing the output of ipconfig or netstat, like it's 1995 again? At least have a command line switch to output JSON or XML.

Did your team talk to any Windows systems administrators outside of Microsoft when scoping out this project's design requirements? Mom & Pop are not managing applications from the command line. Please poll some enterprise administrators and ask them how important they feel it is to have optional but baked-in PowerShell integration (not just basic cli compatibility). Maybe some of them would like to chime in here...

I have my first attempt at a stop-gap PackageManagement provider up on PSGallery this morning, it should work on both PowerShell 3 through 5.1 and 7.0.1+.

I've noticed on first run that it's somewhat flaky about initially caching the package list from the repo if winget has never been used before. Running a cmdlet a second time after initial install seems to work. Still looking into that piece.

Not being able to pull a list of installed packages also seems to give PackageManagement some heartburn..

PS C:\Users\WDAGUtilityAccount> Install-PackageProvider WinGet -Force                                                   
Name                           Version          Source           Summary
----                           -------          ------           -------
PackageManagement              1.4.7            PSGallery        PackageManagement (a.k.a. OneGet) is a new way to d...
WinGet                         0.0.1            PSGallery        Package Management (OneGet) provider that facilitat...

PS C:\Users\WDAGUtilityAccount> Install-Package 7zip -ProviderName WinGet -Force
WARNING: 'WinGet': Get-Package is not supported because WinGet does not support listing installed packages. «-f»
«WinGet»

Name                           Version          Source           Summary
----                           -------          ------           -------
7zip.7zip                      19.0.0           winget

Edit: These issues are now solved. See below.

So this is the second mention of needing powershell operability, and I think what we need is not for this project to provide powershell support directly, but instead provide parseable (not just string) output. The other issue #196 I think summed up the best option for this executable, which is provide a flag to generate json or XML output that is parseable by anything that can handle those formats. I believe that would be the best solution forward, and would also give a way for other systems to use the executable in a programmatic way, not just powershell.

James Maxson (@MaxFrost)

I think that's a decent halfway solution James Maxson (@MaxFrost).

Ideally, we'd get that and a PowerShell module built around that to make handling it easier. Providing parseable output is a good first step, and would at least allow the community to build a powershell module to handle it.

However, I think it'd be a much better idea for the team building WinGet to also build the powershell module so they can have new features handled in the powershell module at more or less the same time as they release new features to the application itself.

I've spent my entire morning building my own PowerShell wrapper. What a mess. What do you think the ratio is of people who will run this in PowerShell vs a CMD window? I crave structured data. Heck, even if you added a -format option to output as json or CSV I could pipe the winget command to Powershell.
I'll also ask why I would use this over the PackageManagement module in PowerShell?

James Maxson (@MaxFrost)

I think that's a decent halfway solution James Maxson (@MaxFrost).
Ideally, we'd get that and a PowerShell module built around that to make handling it easier. Providing parseable output is a good first step, and would at least allow the community to build a powershell module to handle it.
However, I think it'd be a much better idea for the team building WinGet to also build the powershell module so they can have new features handled in the powershell module at more or less the same time as they release new features to the application itself.

People keep on mentioning powershell module, but I just want to stress it that we should focus on PackageManagement Provider (which techincally I guess is a module?), so we can utilize it's cmdlets for consistent experience across different managers.

It would be disappointing if it lacks PowerShell support. I would be happy to get either a CmdLet or a PackageManagement provider.

If you decide to build full Cmdlets, connect with the community early in the process. We are very vocal and good about providing feedback. We also have a good sense of the best practices and how to capture the spirit of PowerShell when creating new CmdLets. Like how naming your object properties and cmdlet parameters the same helps PowerShell to automatically map them on the pipeline without you having to create and manage a mapping between the two.

The provider would actually be the easiest to for you to implement, especially when you are still in development. It has a clear interface, the design requirements are already there, and you are in a place to identify features that would make that integration trivial. Like adding JSON output options that you are more than likely going to add anyway. The only documentation you would need is how to install the provider and an example showing how to download your first package for good measure. The rest of the documentation is covered by PackageManagement. You would reach a user base that already knows how to use the commands. And PackageManagement already has a DSC provider so that fits into your Asure story for host configuration and devops.

Not providing PowerShell support is signalling that this is just a tool for developers written by developers for local system installation. This announcement was timed for Build and what you presented was good for that development focused audience.

Native PowerShell support signals that this is a tool for system admins and system devs that are managing hosts in Azure with or without DevOps and also in corporate networks (especially if they support more than a hand full of systems).

Kevin Marquette (@KevinMarquette)

Kevin Marquette (@KevinMarquette) - you make a good point. I note that all negative social media comments remain without a reasoned response. I did see one MVP who tried to defend the approach but quickly backed down in the face of common sense.

I suspect that someone had a great idea for a new tool. In a common sense vacuum, they developed it in a Linux like fashion (ie random characters that make up this .exe's UI). This means users have to screw around with grep/sed/awk to do anything beyond trivial. What a sad state of affairs.

This reeks of re-inventing a wheel, Haven't MSFT learned the lessons of history? The PMs on this team should be forced to re-read the Monad Manifesto until they understand where they went so wrong.

TL;DR: A company that respects IT Professionals would never have designed this feature this poorly. Management of packages is a management activity that is inherently automatable.

This is very disappointing - another tool I really can not get excited about. It could have been so much better.

How do we use the PowerShell module? I have the latest version, is it already installed? (v1.4.3132-preview)

Look at the assets for the releases on Github. You can download e.g. Microsoft.WinGet.Client-PSModule.zip and load that.

Release notes includes the link to:

Information about getting started and usage can be found here.

When will the module be available in the PowerShell Gallery?

For now, I have created a PR to add the module to Scoop. Once it's merged, you could simply install it from there:

winget-ps: Add version 1.4.10173 ScoopInstaller/Main#4381 (winget-ps)

scoop install winget-ps
Import-Module Microsoft.WinGet.Client

Please add full example to describe the usage of Powershell CLI (both standard pakcage mangement command (such as Find-Package) and specific WinGet commmand (such as Find-WinGetPackage) into the https://github.com/microsoft/winget-cli/tree/master/tools/PowerShell README.md

thanks

We will be publishing another release in the next few days.

I'll be giving a presentation at 2;00 PM on Tuesday April 25th.

I've created:

Publish PowerShell Modules to PowerShell Gallery #3176

After we publish the initial preview release at the PowerShell Gallery, I will be closing this issue so we can track individual Issues on bugs and features related to the Microsoft.WinGet.Client module with the "PowerShell" label.

Demitrius Nelon (@denelon)

Demitrius Nelon (@denelon) can we get an update on this issue when the official release goes out so we know we can start using it? I don't want to switch my scripts over in preview, but would love to do so once this is stable.

https://www.powershellgallery.com/packages/Microsoft.WinGet.Client/0.1.0-alpha

I created a discussion for the new Microsoft.WinGet.Client module.

Microsoft.WinGet.Client 0.1.0-alpha #3182

Squashed 'src/SfsClient/sfs-client/' changes from be733af9..c639a506

Squashed 'src/SfsClient/sfs-client/' changes from be733af9..0e27525d

does these also solve #256 ?

Add native PowerShell winget cmdlet to README.md (#594)

Navigation Menu

Repository navigation

Add Native PowerShell Support #221

Description of the new feature/enhancement

113 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Add Native PowerShell Support #221

Description

Description of the new feature/enhancement

Activity

aglasson commented on May 20, 2020

ethanbergstrom commented on May 20, 2020

AurimasNav commented on May 20, 2020

doctordns commented on May 20, 2020

JasonFossen commented on May 20, 2020

ethanbergstrom commented on May 20, 2020

MaxFrost commented on May 20, 2020

vexx32 commented on May 20, 2020

jdhitsolutions commented on May 20, 2020

AurimasNav commented on May 21, 2020

KevinMarquette commented on May 21, 2020

KevinMarquette commented on May 21, 2020

doctordns commented on May 21, 2020

113 remaining items

krokofant commented on Jan 19, 2023

denelon commented on Jan 19, 2023

sitiom commented on Jan 25, 2023

soroshsabz commented on Feb 11, 2023

denelon commented on Apr 22, 2023

Banner-Keith commented on Apr 24, 2023

denelon commented on Apr 24, 2023

denelon commented on Apr 25, 2023

Xyz00777 commented on Jan 15, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions