When do we begin to see the PowerShell cmdlets?

[doctordns]

Description of the new feature/enhancement

We have previously asked for good PowerShell cmdlet support from the WinGet project.
The team have agreed and there is a milestone. This is good!

Thus far, I have seen no progress, no initial thoughts on how this might work, and no detailed object model or suggested commands.
If the team is to meet that milestone commitment then time is running short (although Covid has probably made any older milestones much more "flexible".

Proposed technical implementation details (optional)

I suggest some draft thoughts and maybe some proto-commands. Not dissimilar to what happened with Hyper-V cmdlets. An early module was published (that was terrible!) but was quickly transformed into a great tool Iand adopted by the Hyper-V team who did an amazing job). Publish the early thinking, and let the PowerShell community help you to do another great job.

[megamorf]

Duplicate of #221.

[doctordns]

It is nor really a duplicate. My issue is asking for early work to be published. Issue #221 is asking for the completion of a fully supported PowerShell module.

Of course, both issues are related - but nevertheless where is the progress against #221? The road map says end-April for full PowerShell support. To have a hope of releasing a good version by then, work has to have started (probably a while ago). This issue is asking the team to expose their thinking one what they plan to deliver (and by when).

This issue can be closed once and an initial set of cmdlets are ready, or when the 1st draft of their specification is available.

And for the avoidance of doubt, my goal is to see a great set of cmdlets that enable IT Professionals to manage the underlying winget feature set. To have good cmdlets with all the qualities of PowerShell but thus far lacking in winget.exe is not an easy task.

[denelon]

As we get "closer" to the feature set intended for 1.0 we will be ready to look at the proper syntax for cmdlets. I'll likely propose some sort of draft via a gist.

[denelon]

I also believe we will be able to iterate fairly quickly once we have clear scope. We will also need to continue revising the syntax as new features are developed.

[doctordns]

I realise you may be new to PowerShell and cmdlets. From nearly 17 years experience with PowerShell, I can tell you that building a huge .exe with it's attendant infrastructure, and THEN trying to back port it to be a great PowerShell modules is going to be very hard work. It's not just a few get/set commands. And the more you bake into the exe, with commands, subcommands, switches etc (all designed without thought of the IT Pro) or how to supp0ort it in PowerShell), the harder it will be to do a great job. Look how much effort it took to get repadmin.exe to be cmdlets (and even then...). Then there is docker.exe with no Powershell coverage either.

You need a strong and complete object model. You need to consider how to override things via group policy. You need to consider format XML, permissions and so much more. These things take a lot of work.

As for iteration, ask the Hyper-V team how much effort it was to build their module; or the AD team. I suggest you should be thinking along the lines of 2-3 months per iteration and not less. Please do not underestimate the task. As I said, If you are to have any hope of even a sub-optimal module by your April goal, you should have started by now. A great module will take longer. This stuff does not spring from the earth fully baked.

For the avoidance of doubt, I want to see a great module to allow IT Professionals to manage packages using this tool. I am looking forward to testing and commenting. But It was Santayana who said that those who fail to learn from history are doomed to repeat it. Please help all of us to avoid that.

[kilasuit]

As we get "closer" to the feature set intended for 1.0 we will be ready to look at the proper syntax for cmdlets. I'll likely propose some sort of draft via a gist.

Surely a draft PR (which is what they are for) would make better sense than externalising this to a gist

[doctordns]

Yes.

A gist is great for a snippet. But as documentation of an important core feature it is wrong.
The reality is, or at least appears to be, the winget team and the teams management just doesn't want to do Powershell.

I continue to believe this is a possibly a very good power toy, but not a serious tool for enterprise use. Yet.

[denelon]

We do want to have a PowerShell cmdlet. Our management supports this as well. We're already looking at some refactoring of the code now to make it easier to support this. There are quite a few substantial changes in the works for the client and the services. It's unlikely that we will land PowerShell in the 1.0 release, but we've already started doing the research and some of the work. Once the new manifest schema and service changes have been done, we will be a step closer. We're building JSON Schemas for everything and we're using them to validate all client side and server side components. That should help standardize the models considerably. We're also building a REST API to enable enterprises to have their own source(s). That will require the client to be able to "speak" JSON.

I'm looking forward to the time when we can collaborate to make sure that we're building the right tools for all of our use cases.

[doctordns]

What that means, in practice, is that there is a much lower likelihood of any PowerShell cmdlets ever. If you do not factor PowerShell into your early thinking, you are going to find, post V1.0, that PowerShell is too difficult. A REST API and json is not sufficient. At a very minimum, you need some reference cmdlets that perform at least the basic get/list/find/update/remove features for winget in V.3 (IIRC this is was the milestone) or for V1.

If you leave it till post V1, you are much more likely face the need for changes that impact on backwards compatibility. The experience of docker.exe should be all the lessons you need. WIth docker.exe fully baked, there is virtually no way we'll ever see supported product team based cmdets. With Server 2022 just around the corner that continues, nearly 20 years AFTER Monad.

I strongly urge you to rethink this and keep to the original plan of having Cmdlets in the earlier pre-V1 release if only to give you self the time to bake cmdlet architectures into your code from the get go. Once you ship V1, your hands really are tied - I speak as one with nearly 40 years of working with MS products (I started with DOS 1.0a).

Please do not drop cmdlets - that time should be NOW.

[kilasuit]

I personally think that PowerShell commands that wrap around the Winget.exe is fine as long as it returns a converted PowerShell object from the output json by default

[doctordns]

As long as there is 100% fidelity, that works. But I would have expected the cmdlet would implement the REST API directly. Converting the string output from winget to an object model may be challenging.,

[kilasuit]

Not really, it just needs a type conversion method that takes the json string input and doesn't need to be a super fancy object that is output either (& the simpler it is the easier it is to maintain and keep current)

[doctordns]

That sounds an incomplete solution. Why not just do not right and do cmdlets from the get-go. As I have said, If MSFT ship winget 1.0 without cmdlets, there probably never will be cmdlets (c/f docker.exe). The dev team are already pushing out PowerShell to post 1.0 by which time it will probably be too late to actually do decent cmdlets. I just do not get why cmdlets are such a big deal here - they are a natural fit for a product that is meant to manage packages.

[denelon]

Feedback from the community is what landed PowerShell on the roadmap. When I joined the project, it wasn't in any of the scope documents I read. As mentioned earlier, we're already doing some refactoring to ensure we can deliver a PowerShell cmdlet. I wish there were enough resources to deliver all of the features that have been requested in v1.0, but that isn't the current situation.

[jantari]

Feedback from the community is what landed PowerShell on the roadmap. When I joined the project, it wasn't in any of the scope documents I read.

That is absolutely insane. Imagine designing a CLI utility but simultaneously completely forgetting the CLI.

Obviously not blaming you or anyone in particular, on the contrary: thanks for the honesty and engagement. I had just really hoped this would finally be the serious package manager Windows has been missing for the last >25 years and not some imprudent throwaway announcement for a quick press hype.

[doctordns]

Many of the posters on this repo have pointed out the lack of PowerShell cmdlets. As I have said several times here, making good PowerShell cmdlets does not happen by accident or via some magic XML (c/f cmdlts from WMI via .CDXML) files.

The lack of movement on a good PowerShell module is why I do not recommend winget for serious package management.

[jbrinkman]

It seems crazy that in 2021, people at MS are building CLI projects that are not PowerShell 1st. PowerShell should not be an afterthought when designing a CLI.

[soroshsabz]

ITNOA

Description of the new feature/enhancement

As you can know PowerShell is great Scripting Language for Automation and Administration of system. and it is built by Microsoft, so I think it is very good for winget-cli to get compatible with PowerShell and make native PowerShell Cmdlet and make great integration with OneGet platform for provide a native and consistent user experience in Microsoft Ecosystem.

In this area we can see below command instead of Linux legacy CLI style like winget install foo

Install-Package foo
Update-Package foo
Get-Package foo

And all of them is object and we can work with them in OOP area with modern and great and consistent experience in PowerShell World.

Proposed technical implementation details (optional)

I think PowerShell has many guideline and documentation about writing and designing great Cmdlet and modules that winget-cli teams have to follow it for example

Windows PowerShell Cmdlet Concepts
Writing a Windows PowerShell Module
PowerShell Script Module Design: Building Tools to Automate the Process
Powershell: DSL design patterns

[JustSomeGuyNZ]

I just wanted to add another voice of frustration here. I'm frustrated at the current lack of progress in PowerShell support. I'm frustrated that this project was allowed to come into existence without being PowerShell centric. But mostly I'm frustrated because it should have been the answer to so many sysadmins prayers.. but right now it's about as useful as tits on a bull.

[denelon]

@JustSomeGuyNZ I'm circulating a draft for the proposed cmdlet nouns and verbs with the PowerShell team currently. I wanted to have them take a look to make sure I didn't do something terribly wrong to begin with. As soon as they have given it the once over, I will be posting the draft specification for community review. We're looking at crescendo so we can do some rapid prototyping and then we will implement native interfaces against the COM API.

[doctordns]

I have learned that the Winget team plan to use Crescendo to build their cmdlets, at least at first. This is very interesting and should get cmdlets out faster. The one HUUUUUUUUUUUUUUUUUUUGE challenge will be to get the objects that are output to be really useful. This is an incredible challenge that I do not for a moment underestimate. Naturally, starting with the objects in the first place would have made so much more sense, but we are where we are. I hope that the WInget team can create some good outputters to make the objects really useful.

If you are not familiar with Crescendo, see: https://devblogs.microsoft.com/powershell/announcing-powershell-crescendo-preview-1/