Repository navigation
Unbundle Pester from PSCore pkg #5458
Description
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
Activity
rkeithhill commentedon Nov 15, 2017
I agree with this with the exception of
PackageManagementandPowerShellGet.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 CurrentUserto 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 commentedon Nov 15, 2017
PackageManagement and PSGet are needed to install from PSGallery so they will, of course, be bundled :)
markekraus commentedon Nov 15, 2017
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-WebDownloadcmdlet 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 commentedon Nov 15, 2017
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 commentedon Nov 16, 2017
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.
Ilya (@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.
Mark Kraus (@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 commentedon Nov 16, 2017
Ilya (@iSazonov) PSCore6.0.0 will be what we call
modern lifecyclewhich effectively meansfix 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 commentedon Dec 1, 2017
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 commentedon Dec 2, 2017
/cc Travis Plunk (@TravisEz13)
iSazonov commentedon Dec 2, 2017
What about Unix? Achieved?
markekraus commentedon Dec 2, 2017
Ilya (@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.