Powershell: Unbundle Pester from PSCore pkg

[SteveL-MSFT]

We originally decided to ship Pester inbox in Windows to help bootstrap the ecosystem with a common test framework. I believe we’ve achieved that goal. We should stop shipping Pester with PSCore6 and rely on users installing it from PSGallery. Long term we should move other modules we ship/own to be available on PSGallery and compatible with a range of PSCore6 versions. This should happen after we update our tests to work on latest Pester

[rkeithhill]

I agree with this with the exception of PackageManagement and PowerShellGet.

On various PowerShell module open source projects (like posh-git), it is very convenient to tell folks that all they need to do is run Install-Module posh-git -Scope CurrentUser to install the module. That simplicity is watered down a lot if you have to put a bunch of verbiage around bootstrapping the package management system first.

[SteveL-MSFT]

PackageManagement and PSGet are needed to install from PSGallery so they will, of course, be bundled :)

[markekraus]

There was a suggestion somewhere that we also split the web cmdlets and JSON cmdltes out. I somewhat agree with that one on the basis that the web cmdlets are browser-ish and may need a more rapid iteration cycle to keep up with the ever changing threat dynamics of the interwebs and increasing feature support in CoreFX for non-windows platforms. But I wouldn't want to have PowerShell Core completely void of a download mechanism, though. So would a very simple Invoke-WebDownload cmdlet that only has a very very basic feature set with only the ability to save to file (no content processing) with separation of some (or all) of the utility cmdltes make sense?

[iSazonov]

What will be the service model for PowerShell Core?
If something like VS Code - we'll publish new stable release every month - the need for multiple packets disappears.
VS Code has a manager for extentions I guess it's overkill for PowerShell..

For example, the Exchange Server team releases new version every 3 months (quarter) and the build expires 6 months later. Also security patches can be released for previous non-expired builds.

[dragonwolf83]

Unbundling from PowerShell Core doesn't have to mean not including as a post-install script. After install, a separate command could be run to install key packages straight from PowerShell Gallery. There is precedence for updating built-in via the web with Update-Help. For those requiring offline installations, an alternate method may need to be figured out.

Another option is to have first-run experience with recommended packages and package collections to install. Maybe a readme on launch with changelog and recommendations.

@iSazonov there is a Chocolatey GUI that someone created to manage choco packages. That might be a good community project to create if there is demand for it.

@markekraus I'm uneasy about breaking out JSON and Web cmdlets unless a post-install script sets it up as a standard install. I get the concern about the agile development, but I think we will see faster releases going forward. If not, then maybe breaking it out will be required. They are just such core experiences that I hate to see it not be there by default.

[SteveL-MSFT]

@iSazonov PSCore6.0.0 will be what we call modern lifecycle which effectively means fix forward only. Barring any critical security issue, customers are expected to install the latest release version (currently planned at 6 month intervals). I think the meta discussion on unbundling other modules and even splitting out cmdlets from monolithic modules should be discussed in different issues. No immediate plans for any of that.

[SteveL-MSFT]

This issue is simply removing Pester from being packaged. The longer item to update our tests to run with latest Pester and removing this fork is not necessary for 6.0.0 release.

[daxian-dbw]

/cc @TravisEz13

[iSazonov]

We originally decided to ship Pester inbox in _Windows_ to help bootstrap the ecosystem with a common test framework. I believe we’ve _achieved_ that goal.

What about Unix? Achieved?

[markekraus]

@iSazonov Considering that Pester is well ingrained with PowerShell at this point, anyone already using PowerShell and moving to Linux will take pester with them. Anyone new to the language will run into pester rather quickly. IMO, The platform doesn't matter so much as as the PowerShell/Pester relationship, which is very strong at this point.