PS Community Call for July 16, 2020

[joeyaiello]

Please add topics/questions for the July 16th Community Call here.

Agenda:

• New releases of PowerShell
  • 7.1.0-preview.5
  • 7.1.0-preview.4
• PowerShellGet 3.0 Preview 6
• Allow explicitly specified named parameter to supersede the same one from hashtable splatting PowerShell#13162
• Update on updateable help pipeline
• Q&A

[essentialexch]

July 15th? That was today. :-)

[kilasuit]

@joeyaiello / @SteveL-MSFT can we please create these issues as soon as possible after the previous call in future? So that things can be upvoted early on if needs be

[joeyaiello]

@kilasuit apologies, that was our intention last time, we messed it up.

@essentialexch whoooops....thank you, and thanks @SteveL-MSFT for fixing it

[kilasuit]

I'd like to see this discussed (even briefly) - #253

[essentialexch]

As Jeff Hicks brought up on psmvp today... [1] Will we be able to get about_* on WPS ever again without building those files?

Regarding Sean Wheeler's blog post https://devblogs.microsoft.com/powershell/updating-help-for-older-versions-of-powershell/,

[2] What does an admin scripter do who doesn't have git?, and

[3] Sean mentioned providing support for the windows-powershell-docs repo. Any update on that?

Thanks.

[Windos]

Any chance we can touch on PowerShell/PowerShell#13042 ?

Just the upstream change and guidance to module authors.

Cheers!

[Ayanmullick]

Could one register one's GitHub repository and install a script from there using the new PowerShellGet module?

Example: Register-PSResourceRepository -Name MyRepository -URL https://github.com/Ayanmullick/PowerShell -Trusted

[iSazonov]

I pulled some PRs to migrate JSON cmdlets to new .Net API and I pulled some PRs to improve FileSystem provider (we could fix over 10 opened issues about performance, symlinks, enumerating).
Is the community and MSFT team interested in continuing me to work on this?

[cameronove]

Can you talk about any improvements for intellisense in Remote-SSH to Windows targets (very delayed), also Ctrl+shft+f won't format code in RemoteSSH and it looks like key bindings in general are a problem there as well.

[iSazonov]

Can we implement PowerShell/PowerShell#3607 based on https://github.com/aaubry/YamlDotNet (de-facto standard implementation) in 7.1 milestone?

[MaximoTrinidad]

Hey... Will Azure Stack and Windows Admin Center support PowerShell 7?

[MaximoTrinidad]

When is .NET 5 Core be released?

[vexx32]

Can we consider PowerShell/PowerShell#12930 for 7.1 or 7.2 please? 🙂

Also cleanup{} 😉 but y'all know about that. Dunno what timelines look like on that, but... you know. 😁

[MaximoTrinidad]

I posted an issue to mention about the Windows Event-ID 53504 PowerShellCore text description: PowerShell/PowerShell#13178

What you guys think about it?

[rjmholt]

When is .NET 5 Core be released?

I think @SteveL-MSFT said it's targeted for November. PS 7.1 is targeted to release simultaneously with it.

EDIT: Here's the roadmap

[iSazonov]

When is .NET 5 Core be released?

November. See https://devblogs.microsoft.com/dotnet/introducing-net-5/

[MaximoTrinidad]

On the issue of missing Windows PowerShell About_* topics, it would be a good idea to add a link to these docs in Windows PowerShell.
:)

[constantinhager]

Any news on PS Secret Management?

[essentialexch]

are there significant issues in ps with the removal of winrt interop?

[iSazonov]

are there significant issues in ps with the removal of winrt interop?

See PowerShell Committee conclusion PowerShell/PowerShell#13042 (comment)

[vexx32]

@essentialexch the main "significant" issue I'm currently aware of is that some of the Windows team modules use WinRT and will need to be updated (likely via windows updates) before they'll work in later versions of PS. The only example I've seen so far has been the AppX module, but there may well be others as well.

[MaximoTrinidad]

Notice the Update-Help issue in Ubuntu/WSL-Ubuntu has been Addressed. Thank You!!
PowerShell/PowerShell#13167

[sdwheeler]

As Jeff Hicks brought up on psmvp today... [1] Will we be able to get about_* on WPS ever again without building those files?

The About_ topics for PS5.1 is a temporary problem. Hope to have it fixed by end of August.

Regarding Sean Wheeler's blog post https://devblogs.microsoft.com/powershell/updating-help-for-older-versions-of-powershell/,

[2] What does an admin scripter do who doesn't have git?, and

The blog post and script was a proof of concept to show you what is possible. It is meant as a temporary solution, if needed, while we fix the publishing pipeline. You can always download the docs repo as a ZIP file from the GitHub web interface without the need to have git installed.

[3] Sean mentioned providing support for the windows-powershell-docs repo. Any update on that?

We are still working on the pipeline but are much closer to onboarding other content outside of PowerShell-Docs. This should happen over the next couple of months.

[MaximoTrinidad]

When is the Azure Shell will be updated to the latest PowerShell GA?

[SeeminglyScience]

AppX for sure doesn't work. See PowerShell/PowerShell#13138

[rjmholt]

@iSazonov @vexx32

I'm conscious of your ongoing work in the repo, and I'd like to personally devote more time to PR reviews to enable it -- hoping to find some more time in the week to set aside for PR reviews. I'm also hoping that @joeyaiello's "subject matter expert" concept might help bring PRs in front of more eyes at the right time. Right now we have something of a bottleneck in PR reviews, and I think PowerShell as a project would probably benefit greatly from community engagement on the PR review side of things.

For the JSON engine refactoring:

• I think we're committed to shipping Newtonsoft.Json with PowerShell, since people depend on it now, whether or not we use it. So taking out the dependency is a benefit we don't get so much from refactoring
• I think that things like the powershell.config.json should definitely use .NET's own JSON parser, especially if we always expect UTF-8
• If we can ensure we have enough tests to guarantee no regressions, I think we can satisfy ourselves that differences in JSON serialisation between Newtonsoft.Json and System.Text.Json are mitigated and we can switch over for JSON cmdlets

I think in the YamlDotNet case, we don't want to bring more dependencies into PowerShell (1) because PowerShell is already huge in terms of size (container image maintainers already balk at this), (2) because it will force other modules to snap to the same dependency version and (3) because YAML cmdlets make perfect sense as an external PowerShell module. I think the right solution here is really to have an "essential bundle" or something similar of modules that "include the batteries" on top of a smaller PowerShell installation.

[maertendMSFT]

When is the Azure Shell will be updated to the latest PowerShell GA?

The version is usually updated on the next Cloud Shell release (occurs every 2-3 weeks) after the PowerShell release. We are in the middle of some larger image changes, so some releases are a little out of sync at the moment.

This is assuming you are referring to Cloud Shell ;)

[vexx32]

@rjmholt yeah, I'm... painfully aware of the roadblocks y'all face with the onslaught of PRs and issues you have to deal with.

If there's a process we can sort out where some community folks can help review things, etc., if there's somewhere I can appreciably help out there, I'm all for it. We're gonna need a pretty clear process to follow though, I think, for everyone's sanity 😁

[kilasuit]

I'm really gutted I missed this call & will have to watch the recording when it's available

[iSazonov]

@rjmholt

For the JSON engine refactoring:

• Common conclusion (of .Net MSFT team too) is that community will move to new .Net API because Newtonsoft.Json is very old, slow and can not be improved. While .Net team is trying to avoid breaking changes, there are many inevitable ones. First experiments show that new cmdlets will inevitably have breaking changes (most ones )
  Without a doubt, with the release of .Net 5, the C# community will actively and massively switch to the new API and the sooner we take this step (I hope in 7.1) the faster and sooner we get feedback and the faster we/users adapt. 7.1 intermediate version with an experimental feature (which can be turned off) works well for this. Also user can continue to use LTS version (7.0). This way also gives time to adapt third-party modules and hosting applications.
  So for the next LTS version (7.2/8.0), all PowerShell community will be ready to move to the new API.

I think in the YamlDotNet case, we don't want to bring more dependencies into PowerShell

YamlDotNet size is surprisingly small (<1Mb)
We could start in PowerShell/Module repository.

[sdwheeler]

YamlDotNet size is surprisingly small (<1Mb)
We could start in PowerShell/Module repository.

There are already 3 modules in the gallery that do this. All of them use older versions of YamlDotNet. I already have issues with this because PlatyPS also uses YamlDotNet. Do we really need this to be in PowerShell?

• powershell-yaml
• FXPSYaml
• Gainz-Yaml

[iSazonov]

Do we really need this to be in PowerShell?

I think so - we see many votes for this. And existence of some community modules demonstrate that it is in demand. (powershell-yaml has over 5000000 downloads!)

I already have issues with this because PlatyPS also uses YamlDotNet.

We could resolve this with custom ACL as @rjmholt blog posted.

[TylerLeonhardt]

@iSazonov can you give examples of where you don't have the ability to install from that Gallery, but you need cmdlets to interact with YAML?

The scenarios I'm thinking about:

• parsing native command output like kubectl - requires you to download kubectl somehow so why not also download powershell-yaml
• interacting Azure Pipelines/GitHub Actions yaml - requires you to push changes to see the pipelines run (thus probably having internet access to install powershell-yaml)

I get that people have interest in YAML cmdlets based on PSGallery downloads, but I don't think the point of the PSGallery was to stomp on existing modules and bring them into the product... but rather the opposite: make PowerShell thinner, and only install what you need.

[iSazonov]

but rather the opposite: make PowerShell thinner, and only install what you need.

@TylerLeonhardt PowerShell team says this many years. I assume that much earlier than PowerShell 6.0 came out. The fact is that high priority principle PowerShell team following is backward compatibility.
Trying to make PowerShell thin looks too timid. The team should first make a public announcement that the next version will be thin and start actively working on it. Since the team cannot decide on this, I would not make such statements as misleading.

In reality, users should not care where the module is hosted. The convenience of access to it is important to them. For personal use only I'd agree to spend a time to find and install a module but not for other, business scenarios. For a container with microservice I'd prefer minimal PowerShell with one module needed for the microservice. For management of large Windows infrastructure I install RSAT with tens of modules. If say about PowerShell 7 install model I'd prefer to have large and well-tested bungle with all needed modules than having a headache installing numerous modules from many repositories with many incompatible dependencies and versions on hundreds and thousands of systems. You can think about Windows Nano Server. You would not agree to put many components on it from different places, you would prefer full Windows server which easily install and service. Conversely, you would prefer Windows Nano bungle if you only need one or two components.
This reduces operating costs and is the main advantage of Windows systems.

If the team still decides to take this step, then they should follow the Windows experience and create useful bungles (like nano, core, full, special/custom - we even have Issue for this) based on PowerShell micro kernel. I'm talking about the micro kernel based on research on unloading modules (@daxian-dbw) and resolving dependency conflicts with ALCs (@rjmholt).

As far as these YAML cmdlets are concerned, users would probably prefer them in a well-tested bungle like RSAT along with the Azure module than wasting time trying to fix installation and dependency problems.

[TheBigBear]

Is there a recording available somewhere?

[vexx32]

@TheBigBear yep! https://teams.microsoft.com/dl/launcher/launcher.html?url=%2f_%23%2fl%2fmeetup-join%2f19%3ameeting_YmFiNmNlMGMtOTFmMy00NmI5LWE1OWEtZTZkMzk2N2I2ZTRk%40thread.v2%2f0%3fcontext%3d%257b%2522Tid%2522%253a%252272f988bf-86f1-41af-91ab-2d7cd011db47%2522%252c%2522Oid%2522%253a%252221cd2cc4-f1fc-4a3b-b13d-788dc099c644%2522%252c%2522IsBroadcastMeeting%2522%253atrue%257d%26anon%3dtrue&type=meetup-join&deeplinkId=e2211174-9c96-48d3-8db9-4b3c124feac3&directDl=true&msLaunch=true&enableMobilePage=true&suppressPrompt=true

In general, the recording is available from the last meeting link. I know they update the aka.ms link monthly before each call, but up till that point the https://aka.ms/JoinPSCall link typically points to the recording of the previous one. They probably have a list somewhere, but I'm not sure where it's at.

[TheBigBear]

@vexx32 Thanks. And one last question ( for now anyway ) and where are the minutes or community call notes filed? I notice the notes section under the rfc https://github.com/PowerShell/PowerShell-RFC/tree/master/notes does not show many or more recent notes? are they public?

[vexx32]

They should be in there, yeah. I think that's usually @joeyaiello's purview for that, but I'm sure it's been a low priority recently with everything else going on 🙂

[joeyaiello]

Apologies. I have a backlog of them that need uploading, I'll try to get to it early next week (this one's kinda booked up).

I really need to automate it all at some point...

[ili101]

@kilasuit

@joeyaiello / @SteveL-MSFT can we please create these issues as soon as possible after the previous call in future? So that things can be upvoted early on if needs be

So, I don't see a new one for this month yet... 😏