Factory wrapper

[denelon]

@JohnMcPMS could you elaborate on the wrapper concept to make implementing PowerShell modules easier to build?

@jantari asked "...what is a "factory style wrapper" and for what work item specifically is a better one needed?"

[jantari]

So in general I am just looking to better understand the progress, new blockers, any shifting goals or moved timelines when it comes to the PowerShell cmdlets.

Your most recent update and the need for a "better factory style wrapper" (for something) is just one example of this, but some place to stay updated on this in general would probably be nice.

I've seen the roadmap and it was great, however - and I have not looked super-deep into how you organize your work here - I did not find any of those "epics" (I would consider these roadmap-items epics, or user-stories, or whatever you call them) either here or here.

So, basically, how would I have learned about the epic I care about ( #221 ) being blocked by a new issue ("new factory style wrapper required") on my own?

I understand #221 itself may not be on the Client-Current or Client-v.Next boards yet as there's no direct work on that happening yet, so I'd instead like to follow the COM API development / epic first. I wasn't able to find that either though, but that may just be my fault for looking for the wrong keywords.

Basically just looking to track the PowerShell blockers/dependencies in the project map so we don't have to harass #221 or create discussions likethis one every couple of months and manually (cynically?) ask for an update, if that makes sense.

[denelon]

I totally get it. That's part of the reason for creating a PowerShell specific discussion area. The good news is we've been working toward PowerShell with nearly every release since the decision to support PowerShell as a native interface was made. It's just been a lot of behind-the-scenes work and not what I would call a linear path.

The CLI was originally built in winget.exe (appinstallercli.exe) and PowerShell wasn't chosen based on some older assumptions. More than three years ago predating my time on the project. Since then, we've had a lot of refactoring work to move the behavior into a COM API such that anyone could integrate with that rather than the CLI. There is still more work to be done, but we're closing the gaps with nearly every release.

I did a hackathon looking at Crescendo which ultimately didn't work out well for us due to the differences in the CLI syntax and PowerShell nouns and verbs as well as the output of the CLI being text and not objects. The biggest value I was looking for was to get some feedback on the proposed cmdlets.

Work is almost never as well organized as I would like (that's on me and not the engineering team), and I'm trying to be very flexible with shifting priorities which makes it much harder for the community to anticipate what's next. That is why the roadmap is so high level and generic.

My current high-level thinking is:

• Create the wrapper/object factory in COM to make it easier to work with multiple versions of PowerShell
• Continue migrating all capabilities into the COM API
• Ensure all new behaviors are implemented into the COM API
• Expose something like "--json" for commands to have output delivered as JSON in the CLI
• Start modifying cmdlets to use the COM API with rich objects for PowerShell
• Build appropriate tests for PowerShell cmdlets
• Sign cmdlets
• Automate building, testing, and signing cmdlets
• Start publishing signed modules/cmdlets with GitHub releases as we make progress
• Publish modules in PowerShell gallery

I'll be meeting with the engineering team over the coming weeks to flesh these out (new Issues) and hopefully make it easier to understand and follow. I'll update the main description for:

• Add Native PowerShell Support #221

I've been hesitant to publish modules in the PowerShell gallery until we have full parity with the CLI. I'm open to feedback here on whether there is value to publish partial feature parity to the PowerShell gallery or not.

[jantari]

Your high-level plan reads pretty reasonable.

Additional note, as the PowerShell cmdlets come back (aka. start to use the COM API) I'd personally prefer to have them in their own repository.

I've been hesitant to publish modules in the PowerShell gallery until we have full parity with the CLI. I'm open to feedback here on whether there is value to publish partial feature parity to the PowerShell gallery or not.

I'd say, assuming semver for the cmdlets/PowerShell module, we can have partial feature parity in the 0.x development releases and then release 1.0 when the cmdlets have feature-parity. The PowerShell gallery supports the notion of publishing "prerelease" versions that users have to explicitly opt-in to installing with Install-Module -AllowPrerelease

[denelon]

@jantari

I had initially thought about having a separate repository for the PowerShell modules, but many on the team felt it was better to keep the modules in the repositories with the code they integrate with. We're already spanning four repositories today, and it makes Issue management and integration a bit more complex than it might otherwise be. We will likely need to modify the project folder structure a bit to make the PowerShell code in each repository a bit more consistent to locate and understand.

RE: feature parity-

It will change a little of the sequencing since we will need to have the tests and signing in place for each cmdlet as we go. Unless I hear strong opposition, I think we can make this this plan/approach. After the holiday weekend, I'll meet with the team to discuss the work breakdown and start creating the Issues. Hopefully that will help provide more clarity to the community with respect to the work that needs to be done and how much progress is being made.

[JohnMcPMS]

I personally would not have heavily advertised what I see as a small step towards making integration with the COM API easier for C#. Yes it is on the PowerShell path, but it is only a small part of it.

The largest complication with consuming it to this point has been that activating an OOP COM object was not simple. The .winmd that defines the interface is only the interface, and doesn't allow for new PackageManager(). The goal of the discussed work is to leverage the learnings of the Store team to ship a version of a CreatePackageManager style function that works for .Net Native and Core. This can then be consumed by the Store, a PowerShell module, etc. to make using it easier.

[jantari]

Don't fault the man for communicating openly in an open-source project 😉

But thank you for the additional context, together with the blog post from the Store team I now get what is meant.

[kort3x]

"PowerShell wasn't chosen based on some older assumptions"

I would love to know more about these assumptions but I bet we never will.

[denelon]

#221 (comment)

[kort3x]

Like @jantari pointed out in that threat it seems like an odd requirement.

Especially coming from @joeyaiello - wasn't he like head of the pwsh team at the time?
Shouldn't the head of that team push for pwsh support?

@denelon
Thanks for being open and good luck cleaning up other people's mess.
I hope winget will get propper pwsh support in the end. <3