winget-cli
winget-cli copied to clipboard
microsoft
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.
I think that's a decent halfway solution @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?
I think that's a decent halfway solution @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).
@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.
I think the ultimate question is "Who is the target user for this command and in what likely use case?". I get the feeling this is designed and targeted at developers who might run this from a CMD prompt or somehow incorporate it into their projects.
Sure... but even then, really, PowerShell is the default Windows shell nowadays, and there's no effort to integrate this with PS even on the roadmap.
This is very much the behaviour I would expect out of winget-cli. Really stops me from deep dive into it on the whole estate!
Simply making winget produce 'better' text really misses the point. A real package management tool would today be based on objects with PowerShell. This tool is not an enterprise management tool or even part if an overall management solution. I see it as a developer tool and little more.
@jdhitsolutions Jeff - I agree that this tool seems to be targeted at the developer running WIndows, with some Linux background who use this tool to manage their local development boxes. IT Pros, these days, expect PowerShell, remoting via PS remoting, and a rich object module. They expect to be able to script based on rich cmdlet output. They expect to use that rich model for reporting.
Devs with LInux experience necessarily have different expectations base on Linux. They do not mind the string output as they can grep/sed/awk their way to hacking automation. And for this persona, many of the features are important to IT Pros are less relevant for a dev managing his/her own local workstation.
But whatever the target market, winter is not an package manager in any sort of enterprise sense.
Sure... but even then, really, PowerShell is the default Windows shell nowadays, and there's no effort to integrate this with PS even on the roadmap.
In this day and age, I would have expected the team to have started with a rich object model, then build the classes to support them, and finally layer the cmdlets on top. That gives you the ability to use the cmdlets as is or leverage the objects for more complex automation and/or reporting in an enterprise management setting.
This could have been so much better. :-(
There's still time for this to "be so much better". There has only been 1 release with obviously a lot of work ahead. Especially if the goal is for true package management and not just another way to install something. All we can hope is that our comments reach the right ears and have the right effect.
One of the initial goals is to make sure the Windows Package Manager works on earlier versions of Windows without a PowerShell dependency. That is one of the primary reasons this is a .exe and written in C++.
@denelon I'm sorry but that argument is void.
Windows 8.1 and Server 2012 are the oldest platforms that are still officially supported (extended support) and they shipped with PSv3. Windows 7 which has reached EOL shipped with built-in PSv2 and newer PS versions have been included in all subsequent Windows client and server releases. Platforms in extended support don't receive new features so they are not your target anyway.
if you want to cover everything in support:
- https://docs.microsoft.com/en-us/powershell/scripting/powershell-support-lifecycle?view=powershell-7#release-history
- https://support.microsoft.com/en-us/help/13853/windows-lifecycle-fact-sheet
Edit: Also, C++ at this point in time seems to be a suboptimal choice when there are newer fast/secure alternatives like Golang and Rust.
That is really not a great answer, in my view. MSFT and the industry have settled on PowerShell as a key automation tool for the IT Professional. Package management, that is the management of packages on a host, is a configuration management problem that is inherently automatable.
For any organisation, automation of Windows means PowerShell. Winget may do cool things, but it is by design MSFT made it harder to automate and harder to scale for an enterprise. It has, in my view, made a bad choice and one that is now harder to fix without a major bit of rework. Slapping cmdlets on top of an exe is not the way forward either. Lipstick on a pig, etc.
The team should go back to basics, define a rich object model, then add that model to .NET Core. The cmdlets almost write themselves. The feature would get much wider adoption instead of being a developer power toy.
There is one way to provide structured/object-oriented access to winget without the need to maintan a separate PowerShell module AND without re-working winget itself to be C#/PowerShell.
- All functionality of
wingetis moved to a native C++.dll winget.exewill just be a tiny wrapper for calling into that dll- The dll will have all the needed functions exposed as public, and it can be imported in C# and PowerShell through
[DllImport()]
This way we all get what we want - a PowerShell wrapper could also easily be community-maintaned - and it's 0 extra work for the winget devs.
Why not just make them .Net (core!) classes?
It's a Windows-only product, and .NET Core is not bundled with Windows. It would be a ~60 MB executable OR require .NET Core to be installed. Makes little sense when .NET Framework 4+ or a native C++ program "just work" on Windows 10 and Windows Server out of the box.
@RichiCoder1 Those "SKU" links in #184 are quite unspecific to be honest. The only platform that really stands out is IoT. All other SKUs with mainstream support (Windows 10, Server 2016/2019) ship with PowerShell.
Nano has been turned into a Docker-only platform and comes with PS Core. Since it's best practice to build lightweight images you'd use a multi-stage build where you install winget and the required packages in the first build stage and use it to copy required artifacts to a second build stage.
It really seems counter intuitive to neglect all the integrations that have essentially been enabled by the implementation of the Monad manifesto over the past 14 years.
@megamorf Which leads me to agree that not even a roadmap item mentioning PowerShell is quite an oversight, but I agree with the decision to make the base-level client a native CLI per the currently top voted comment.
Then we say make them target DotNet standard. PowerShell allows you to build binary modules in C# that run on both the old version that uses DotNet Full and the newer PowerShell that uses latest DotNet Core. For that matter, you don't even have to move away from C++ for your base libraries and winget executable. If you can import them into C# as a dependency, then the CmdLets are just wrappers around the API calls. This is especially true if your data view models are in the library too so your executable is also just a thin wrapper around it.
If the project ultimately decides not to add native PowerShell support, then make it easy for the community to build their own tools. Provide a .Net library as a nuget package so they can consume it from C# without calling out to the shell over and over to invoke the winget executable.
As a developer, I expect Powershell support too. Literally the first thing I did was pipe to 'where' and then 'sort' to get a list of the packages available then got confused when it didn't work.
If this needs to run on embedded devices and work in CMD, great, but please maintain and install a version that works with Windows' default shell for everyone else.
