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)