Winget-cli: Add Native PowerShell Support

[ThomasNieto]

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.

[aglasson]

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?

[ethanbergstrom]

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.

[AurimasNav]

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.

[doctordns]

• 1 on this.

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

1. No Get-Help - existing help is thin to say the least
2. inconsistent command structure
3. No objects emitted or taken as a parameter
4. No Tab Completion making it harder to use
5. Output is string so no Get-Member to discover output - less discoverable
6. All in all harder to automate programmatically without having to go back to the stone age with grep/sed/.awk
7. 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.

[JasonFossen]

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...

[ethanbergstrom]

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

[MaxFrost]

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.

[vexx32]

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.

[jdhitsolutions]

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?

[AurimasNav]

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.

[KevinMarquette]

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.

[KevinMarquette]

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).

[doctordns]

@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.

[jdhitsolutions]

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.

[vexx32]

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.

[virtualas10]

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!

[doctordns]

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.

[doctordns]

@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.

[doctordns]

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. :-(

[jdhitsolutions]

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.

[denelon]

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++.

[megamorf]

@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.

[doctordns]

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.

[jantari]

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.

1. All functionality of winget is moved to a native C++ .dll
2. winget.exe will just be a tiny wrapper for calling into that dll
3. 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.

[doctordns]

Why not just make them .Net (core!) classes?

[jantari]

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.

[megamorf]

@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.

[RichiCoder1]

@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.

[KevinMarquette]

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.

[mikemaccana]

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.

[doctordns]

Over time, most folks managing a host's packages would want to do so in an automated fashion. And that is more so in the Linux friendly environment we find ourselves in. Didn't we get told that Linux folks would write scripts the moment they had to do something more than twice? Managing the packages on a host really means PowerShell since Winget is not really an automatable tool in the way we have grown accustomed.

Most developers, I'd have expected, would have loaded PowerShell core anyway so I don't buy that argument. ANd any developer who is going to use winget, would be loading far more than a few MB of .net Core. How big is Visual Studio? Or any of the other tools??

You could still target DotNet standard. build your modules in C# so that they run on .NET Full and .NET Core, and then you have the best of both worlds (and Linux compatibility too). The dev team should have known that, and have come up with a good reason for not doing so (and they haven't yet.

At the end of the day, the approach taken was suboptimal - the issues raised here are proof of that. The building of an incompatible non-extensible self-contained .exe, Windows only, is just hard to defend except as another example of a PM doing it because he/she can.

If we need another Package Manager on Windows, let's do it properly. Let's have a decent (and leveragable) object model and build proper cmdlets. You can probably strip out a bunch of code from winget.exe by letting Where-Object, Sort-Object, etc. do all the heavy lifting leaving winget to do what it needs to and not duplicate things Admins need.

This could have been so much better.

[Stephanevg]

I am surprised that Powershell support was not planned for this from the start.

Powershell has the same kind of mechanism called 'PowerShellGet'. This is currently beeing re-engineered / refactored for a new version 3.0. It is still developement, and it's RFC is still open -> https://github.com/PowerShell/PowerShell-RFC/pull/237

@JohnMcPMS (Hoping you are the maintainer of the project as you have the most commits on this repo. If not, could you please make sure this message reaches the owner of the project?).
You should defintley get in touch with @SteveL-MSFT / @SydneyhSmith (respectivley owner of Powershell, and owner of powershellget)

[iSazonov]

Taking into account that PowerShell is portable, I would be very surprised if this new project WinGet was not immediately designed with the same intention.

[kilasuit]

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++.

Considering all supported versions of Windows either have PowerShell support or are on the roadmap to have native support (thinking here the ARM64 version of Windows is the only version I am aware of that yet doesn't have PowerShell Support) I feel that this is a moot point, even Nano Server has a thin version of PowerShell that was partially the precursor to PowerShell going open source in August 2016.

Unfortunately the choice made here to start building a "Windows Package Manager", in my educated opinion having been a huge part of the Windows Automation community is that winget is at least a good 4-6 years too late, & much more so that this was done back with OneGet (aka PackageManagement) and that lost traction. Much of the market that were looking for a package manager for use on Windows, have long embraced Chocolatey because it was, is and will continue to be the best in breed across the ecosystem. Winget will not change that.

However, this I feel could address this Issues request & I would see this as possible win, though it's suboptimal experience in my view

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.

1. All functionality of `winget` is moved to a native C++ `.dll`

2. `winget.exe` will just be a tiny wrapper for calling into that dll

3. 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.

However, I have more pressing and important areas to focus my time on, so I won't be adding any further comments, nor do I intend to move away from Chocolatey either. Best of luck with this project, to gain the support of the Windows Automation community you will need to invest in providing better support of PowerShell going forward.

[doctordns]

Taking into account that PowerShell is portable, I would be very surprised if this new project WinGet was not immediately designed with the same intention.

It does not appear that that was the case. It appears that this is a standalone effort largely in isolation from the IT Pro community.

I really do not get why this was built without, apparently, any thought to automation by IT Pros. Since November 2003, the direction has been _towards_ PowerShell. This is another move away from it. I really would like to love this tool, but the focus is just so wrong.

I hope the development team are reading this and othe threads and are going to do their right thing.

[majkinetor]

Without having PowerShell support internally when installing is no go for me. Its simply not possible to create a package manager declaratevelly without some serious scritping involved, and especially on Windows where commune is far from package manager friendly mindset and include all kind of quirks during installation, where even Powershell may not be enough but some automation tool like AutoHotKey.

Not only does it need Powershell during package install, but also some automation on package maintenance, like the one I did for choco - AU. Without such thing, you quickly get overloaded with non working packages due to the upstream removal, silent updates that change no version but only checksum, network preventions etc.

[megamorf]

Don't worry guys, this is being worked on behind the scenes.

[doctordns]

That is good news. I just wish the Winget team had been clear that a good PowerShell solution would come.

[mikemaccana]

The slide is great, but what would even be better is someone from Microsoft saying ,"yes, in future winget will work with powershell out of the box"

[whitTech]

Don't worry guys, this is being worked on behind the scenes.

Great find, @megamorf.

Reassuring comment from Sydney in the linked video:

@40:36 - "[The winget team] are very . . . understanding . . . of the importance of PowerShell integration and support."

Additionally, I believe you guys are being provided some recognition, which is very nice of Sydney.

@40:43 - "I also just really want to shout out you guys for opening that issue on the repo and really showing how vibrant the PowerShell community is. That is huge and goes a long way in terms of making this integration story come together by the time of GA next year."

Thank Lucifer we're not actually being dragged back to string parsing and that objects are still the focus for development. You have my tentative thanks in advance, team/s.

[SteveL-MSFT]

To clarify, the WinGet integration is about when you get a CommandNotFoundException, PowerShell could tell you what to install via winget to get that command. I would also caution against spending time implementing a PkgMgmt provider for WinGet as there are no plans to invest in PkgMgmt.

[ferventcoder]

Not to put too fine a point on it, but one of WinGet's mantras (and why not to look at Chocolatey as a good model instead of building their own) is NO SCRIPTS - this was mentioned here https://devblogs.microsoft.com/commandline/winget-install-learning/ (emphasis mine):

There are a number of qualities in AppGet that really helped us get to a better product direction for WinGet:

• No scripts during install – something that we completely agreed with and don’t allow with MSIX
• Rich manifest definition within GitHub – the power of being open combined with rich declarative meta data about the app is so important to meet goal #1
• Support all types of Windows applications installers
• Seamless updates for applications in the repository

All of the other points are things on the roadmap for Chocolatey (declarative model in addition to existing imperative w/PowerShell), better model for upgrades in an automated sense, everything else is already there.

[jantari]

@ferventcoder this issue isn't about adding install scripts to winget like chocolatey, it's about PowerShell commands to use winget

[ferventcoder]

@jantari My bad. I'll hide my comment and see myself out - I think I got confused by other comments in here that lean the same way I read this.

[ferventcoder]

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.

@AurimasNav just a heads up - https://github.com/chocolatey-community/Chocolatey

[doctordns]

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.

@AurimasNav just a heads up - https://github.com/chocolatey-community/Chocolatey

It would appear that all that wonderful PowerShell goodness (rich objects, usable help and error messages, tab completion, case-insensitivity) was were not design goals for WinGet. It appears that, despite the "win" in the name, this is very much a linux/unix style product with none of those good things we IT Professionals have gotten so used to. Maybe it should be renamed LINGET?

From the lack of formal comment on this point, I suspect you are going to have to live with this and move back to SED/AWK/GREP to do the string processing necessary for automation (and NOT needed has this been PowerShell) - at least for the short term.

I note the slide in this thread and that is hopeful. But so far, details are very thin. I am really hoping that the LInGet team can make decent cmdlets that enable IT Admins to manage packages using PowerShell. I just hope the WinGet team do not model WSUS if and when they build cmdlets.

[JohnMcPMS]

Wanted to comment to let you know that I do see this, and I agree that this would be a very good thing. I'm not the one deciding exactly what gets done, but I suspect that as one of the top upvoted issues, this will be worked on.

I'm no PowerShell expert, so it will take some learning to see just how this can be accomplished (if at all) against the current ship vehicle of an MSIX package. If not, we will work it out (with you) what the best course of action is.

Lastly, I would ask for your understanding. We wanted to put a minimal product out and then work to provide what the community wants, rather than taking much longer to give you more of what you didn't. As some have intuited, the initial target was "make it easy for developers to install tools." We have a lot more work to do to fulfill the promise of our name, and I think that native PowerShell cmdlets will help get us there.

[Karl-WE]

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++.

I clearly agree to the majority of comments that winget should not be developer oriented but admin /DevOps oriented

Without powershell support it, promised it will be niche tool for fact. Eventually MECM community might adapt.

Powershell will put it from niche to nice, if you allow me this pun.

I appreciate the spirit of winget and already love using the tool for quick manual single point deployments.
@jdhitsolutions has a quite sharp view on this.
Often enough I see that things that could be easy are getting complicated.

Referring:

• my PRs about syntax inconsistencies (without reading docs from the first sight). @denelon and @megamorf are in the loop.
  Like
  

  479 #282 etc.

Or off topic referring:

• installing and updating Powershell 6 Core and 7.x before winget and before @jdhitsolutions made his installer module.

• WindowsTerminal team now regrets decision to json to manually config it for users before a GUI was ready.

Pardon if it reads offtopic.

My goal is to display that, with concluding the most of reactions and comments here, winget should not be the 5th way to install apps on Windows, but should become the best yet ultimate way doing so, for home and definitely for IT pros, familiar to Windows and Linux.

Stepping winget to PowerShell will create dependencies, c++ does, too (redists).
PowerShell support will ultimately join winget with Windows Admin Center, which is a great helper, especially in SMB.

Even a software deployment and repository management module in WAC would be imaginable. @jwwool

Given the good anticipation of WSL2 and cross platform support of PowerShell 7.x, it's worth it twice maintain the dependencies across MSFT product teams and the community / users 👥
🙏🏿

A last note on dependencies:

I'd plea to focus on PowerShell 7.x as this is the active branch and due to support limitations we won't have to fiddle with 5.1 anymore, given Winrm will move on to require PS 7.x too in the next years.

[doctordns]

In May, in this thread, I pointed out the shortcomings of the rather narrow-minded approach taken by the development team. Since then, I have seen nothing tangible that suggests the development team has understood the issues raised

If Microsoft wants to make power toys for developers who want to get stuff onto their machine, great. But be honest about it (and make sure I can disable winget to avoid having to fix borked dev machines). But If Microsoft wants a real professional tool, one that can be used by IT Pros and developers alike, they need to think again.

And sadly, I see no recognition of this point.

Such a shame as this could have been a really great tool.

[megamorf]

@doctordns Most of your posts in this issue seem to be just complaints without offering anything of value. There is a development roadmap with milestones and you can see when which issues will be worked on. It's fairly transparent and don't forget that maintaining the infrastructure, grooming the winget-cli and winget-pkgs issues as well as discussing implementation details among the team members all take up time that cannot be spent on actual programming work.

There are more troubling user experience issues that need to be resolved right now than producing a sub-par PowerShell implementation that you'd criticize anyway. Don't get me wrong, I'd love to interface with winget via PowerShell but it makes more sense for winget to be able to skip installation for existing software and uninstall packages before they do a PS deep-dive.

[doctordns]

Sorry if you feel that way. My fear is that winget will end up like docker.exe - a self-contained exe that has no PowerShell support. If the team does not start focusing on how to deliver a 1st class PowerShell experience very soon, then I fear it will be too much work down the line. I have seen this before - and I'd hate the future of Windows to go this way if it can be avoided. You mention the roadmap - this document does not mention PowerShell. It is not included in any of the V1 scenarios. I was very pleased to see GPO support (if I had not said so before).

I have offered, perhaps elsewhere, some specifics. You start with a good object model. What are all the specific objects and their relationship to each other? If the intention is to ever produce a PowerShell module, this is a discussion that shoudl be had now not in May 2021 at the sart of V2. From that, the cmdlet names flow (you already know the verbs!) and to a degree, their behaviour is obvious (once named Get-Application gets applications, etc). With cmdlets all those things that are missing today (noted in my earlier comment) become visible and available - and something to really push in the IT Pro market. Creating the help content and the docs are work to be done (and I'm only too happy to help).

Will the first pass of cmdlets be great? Ask the Hyper-V Team. :-) The first Hyper-V Module was awful but with feedback got much better. I would expect precisely the same kind of thing with winget cmdlets, were the team to go down that road. They get better with time and I am only too happy to help with that and to ensure the cmdlet documentation is great.

Another suggestion is to ensure the winget Verb names are at least compatible with PowerShell verb names, so Get, instead of Show and Test rather than validate. if the team has to go their own way with an exe, please, please don't build incompatibility with 15 years of PowerShell where you do not have to.

[Karl-WE]

"Most of your posts in this issue seem to be just complaints without offering anything of value"

I think this is a productive idea that can be still implemented by now, because winget cannot yet be widely tied into scripts yet.
If you are concerned about renaming, ask the Windows and Office teams, they rename and redesign their deployment stuff all the time, even with productive impacts. Don't be afraid.

"Another suggestion is to ensure the winget Verb names are at least compatible with PowerShell verb names, so Get, instead of Show and Test rather than validate. if the team has to go their own way with an exe, please, please don't build incompatibility with 15 years of PowerShell where you do not have to."

[Karl-WE]

@doctordns can you please file a feature request for this snippet? It is your idea. I'll support it.

[kilasuit]

Some comments on this & whilst my comments may slightly counter @SteveL-MSFT comment about the longer term life of PackageManagement, I personally really still like the idea of a centralised "Package Manager" Manager, which was OneGet aka PackageManagement's original goal, for use across Systems (windows & linux) & would still like to see the OneGet aka PackageManagement get longer term investment in simplifying how it works to manage all package management systems

@doctordns I think that proper PowerShell support for winget will ultimately need to come into the realm that was PackageManagement aka OneGet and that it is delivered with an incredibly simple shim PackageManagement Provider that essentially allows an admin/developer/user to run something like this on windows

$Packages = @(
    [PSCustomObject]@{
        PackageName = PowerShell
        Source      = winget
    },
    [PSCustomObject]@{
        PackageName = PSKoans
        Source      = PowerShellGallery
    },
    [PSCustomObject]@{
        PackageName = VSCode
        Source      = chocolatey
    },
    [PSCustomObject]@{
        PackageName = leftpad
        Source      = npm
    },
    [PSCustomObject]@{
        PackageName = MSIApplication
        Source      = MSI
        Path        = $MSIPath
    }
)
)
Install-Package @Packages

or this on Ubuntu

$Packages = @(
    [PSCustomObject]@{
        PackageName = PowerShell
        Source      = apt-get
    },
    [PSCustomObject]@{
        PackageName = PSKoans
        Source      = PowerShellGallery
    },
    [PSCustomObject]@{
        PackageName = VSCode
        Source      = apt-get
    },
    [PSCustomObject]@{
        PackageName = leftpad
        Source      = npm
    }
)
)
Install-Package @Packages

instead of needing to use another separate module.

That is what I would like to see happen for proper PowerShell support, as there isn't really a need to do much else if the shim provider does all the leg work for us, which seems viable with the design here for winget particularly when you have comments like this already in the thread

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.

or this comment

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.

and whilst I said this

However, I have more pressing and important areas to focus my time on, so I won't be adding any further comments, nor do I intend to move away from Chocolatey either. Best of luck with this project, to gain the support of the Windows Automation community you will need to invest in providing better support of PowerShell going forward.

on further reading this thread and seeing this from @jdhitsolutions, I have to say I agree with him completely here

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.

because what we really want is a true and tested method to be able to install all types of packages without too much overhead, which is\will be OneGet/PackageManagement

When we get another year (or 3) down the line, we will see it happen, but it will need to see PackageManagement rebuilt with better shim support as opposed to what we have now with dedicated native & clunky support & is the only the sensible way to get actual PowerShell Support for winget in the future.

[johan-boule]

@megamorf

Also, C++ at this point in time seems to be a suboptimal choice when there are newer fast/secure alternatives like Golang and Rust.

For all I know C++ is the very optimal choice, by far, compared to Rust and Golang. I wouldn't be surprised the latter two actually depend at least on the C runtime.

[jsoref]

It appears that Rust today does rely on the C runtime (but theoretically doesn't have to): https://stackoverflow.com/questions/27723617/why-do-executables-have-a-dependency-on-glibc

It appears that some Golang programs may not depend on the C runtime: https://stackoverflow.com/questions/41720090/does-go-depend-on-c-runtime

[jantari]

For all I know C++ is the very optimal choice, by far

Without any good reasons why that is a useless comment. Take a look at the wireguard source code to get an idea how nice and easy it is to call Windows platform APIs from Go code: https://github.com/WireGuard/wireguard-windows/search?q=golang.org%2Fx%2Fsys%2Fwindows&type=