PowerShell 7.1 Team Investments and Preview.1 Release
The PowerShell 7 release marks a huge milestone for PowerShell, the community, and the team!
Today we released the first preview for PowerShell 7.1! This release includes a number of changes that did not make it in time for the 7.0 release. It also includes .NET 5 preview 1!
The PowerShell team is not resting on our laurels and are committed to continuous improvement of PowerShell as we plan out our 7.1 release. This blog post details the areas of investment that the PowerShell team is funding. As we’ve done in the past, we’ll also be working with contributors interested in implementing new features as part of the 7.1 release.
Release Cycle Changes
PowerShell Core 6.0 through PowerShell 7 was on a (roughly) 6 month release cadence.
Starting with PowerShell 7.0, we shifted to align with .NET’s release and support life-cycle more closely. This means we intend to ship 7.1 within a week or two of .NET 5’s release date of winter 2020 and align with their annual release cadence going forward.
Modules and Tooling for the 7.1 Release Time Frame
Not everything here is expected to ship with PowerShell 7.1, but the work is being done along with PowerShell 7.1 development.
At the beginning of PowerShell 7 development, we announced PowerShellGet 3.0. This is a complete rewrite of PowerShellGet covering 3 big areas:
- Improving the user experience
- Removing dependency on PackageManagement (and Nuget provider) making the codebase simpler and easier to maintain
- Moving from PowerShell script to C# making it easier to maintain a large and complex codebase
Based on community feedback, we wanted to take an opportunity to address many of the user experience shortcomings with a major release that will have breaking changes. We also want to leverage learnings from popular package managers like
apt (on Linux) to adopt conventions already used and proven by a large set of users.
PowerShellGet 3.0 will ship on PowerShell Gallery initially, with tentative plans to deliver it into PowerShell 7.x side-by-side with PowerShellGet 2.0.
The first preview is expected later this month!
Secret Management Module
We are still working on completing Secret Management module, specifically adding Linux support, possibly macOS support, and continuing to address user feedback.
We received lots of good feedback from our preview 1 release which helped shape our preview 2 release. Thanks so much and it shows that getting previews out early really helps the project!
This module is shipped via PowerShell Gallery supporting Windows PowerShell 5.1 and PowerShell 7 and potentially included by default with PowerShell 7.1. This module enables secure storage and retrieval of secrets locally as well as using extensions to store and retrieve secrets from remote vaults (like Azure Key Vault).
We are also working with partners to have vault extensions available soon!
VSCode-PowerShell, PSEditorServices, and PSScriptAnalyzer 2.0
The PowerShell extension for Visual Studio Code and PowerShell Editor Services rely on PSScriptAnalyzer to perform real-time linting as you author or edit a PowerShell script. However, this scenario was not part of the original intent nor design of PSScriptAnalyzer and thus has become a user experience where errors and corrections lag after the user input. Major portions of PSScriptAnalyzer needs to be updated or rewritten to significantly improve throughput to make the interactive user experience more instantaneous, delightful, and productive.
PowerShell Jupyter Kernel
Jupyter notebooks are gaining popularity as a way to have executable code and text content in the same document. There have been existing Jupyter kernels available that support PowerShell, however, we wanted to invest in this space with one that would be supported by the PowerShell team and providing a complete experience.
We’ve already shipped the first preview of our PowerShell sub-kernel that is part of the DotNet Interactive Jupyter kernel.
We will coontinue to improve this experience making it a great choice for PowerShell and Jupyter users.
PlatyPS is a PowerShell module that we currently use to convert PowerShell documentation from markdown to updatable-help and is available via PowerShell Gallery. Based on feedback from content authors and partner teams, we need to invest in this tool to improve the author experience as well as improving capabilities of our documentation. This will be a rewrite to support improved Markdown parsing, rendering, and fulfilling requirements for our internal pipelines to publish updateable help.
Themes for PowerShell 7.1
Installation and Updating
A major pain point for our customers, particularly on Windows, is that installing and updating PowerShell 7 requires too many manual steps. We are exploring some options to make it easier to install as well as keep PowerShell updated. At this time, we still do not have a plan to ship PowerShell 7 in Windows due to differences in support requirements that we are still working through.
Most native commands work just fine from within PowerShell, however, there are some cases where the argument parsing is not ideal (like handling quotes properly). The intent is to enable users to cut sample command lines for any popular native tool, paste it into PowerShell, and it just works without needing PowerShell specific escaping.
In addition, for advanced users that want to mix PowerShell specific concepts with native commands, things may not work as expected. For example, PSDrives are a great way to abstract a file path across operating systems, but only PowerShell cmdlets and scripts can use them. We want to explore how to expose these things to native commands.
Interactive User Experience
To enable users to be more productive at the shell, we want to enable two new scenarios:
- Enable predictions: We are investigating how the community can author different prediction engines helping the user complete a pipeline with minimal typing.
- Enable dynamic help: While authoring a pipeline in the console, the user should be able to get context aware help like presenting help on parameters as they are typing or get full help content without having to abandon their current input or open a new console.
- Enable use of color: We added some additional use of color in PowerShell 7.0 to provide visual cues when scanning console output. For 7.1, we are working with the .NET System.CommandLine team to have appropriate APIs to decorate strings so that PowerShell can render them both with color as well as plain text, as needed. This includes addressing accessibility concerns where certain colors, themes, and decorations may be hard to see.
These experiences will require changes in both PSReadLine and the PowerShell engine itself.
We are also exploring some experiments such as
Out-ConsoleGridView to make the console an even more productive experience.
One of the great things about PowerShell is the plethora of APIs and cmdlets you can use. However, the cost of this is that lots of assemblies are included with PowerShell just in case a script uses them. This works fine for authoring scripts, but when deploying scripts, it would be better to have your target only install the parts of PowerShell needed for those scripts. Not only would it take less disk space, but more importantly, a minimal set of code means less patching and security attack surface.
As part of this effort, we also want to split the monolithic Utility, Management, and Security modules that ship with PowerShell into logical modules that can be innovated and published on their own cadence.
Finally, to improve performance, we also want to look at reducing dependencies on .NET assemblies that are not absolutely needed to reduce memory usage as well as improve startup time.
As you can see, there is a lot of work we are current exploring and prototyping. Not everything will make it into the 7.1 release and may show up in a future release. As we make progress and have more concrete definitions and scope of the work, we will publish RFCs to get community feedback like we’ve done in the past. We will also leverage GitHub Projects to track progress and enable the community to provide feedback. I’m personally excited about the future of PowerShell and looking forward to seeing feedback on our plans!
Steve Lee Principal Software Engineer Manager PowerShell Team
RE improvements to using native commands, I’d love to see improvements in how native command exit codes are handled. In build scripts, you almost always want a native exe exit code that indicates failure to fail the script. Today, you have to jump through hoops to get that to happen (inspect $LASTEXITCODE and throw on error). We need something akin to *nix shell’s `set -e`.
Related to *using* native dev tools, I’d like to see PS be able to invoke a batch file and have PS retain all the environment variables changed by the batch file. This is a common need with Visual Studio VC++ config batch files. Perhaps this could be done by changing how dot sourcing a bat/cmd file behaves. Dot sourcing a batch file could be changed to retain changed/new/(deleted?) env vars e.g.:
While `.\vcvarsall.bat` and `& ‘.\vcvarsall.bat’` would continue to behave as it does today.
Not having to use Import-CmdEnvironment would be a nice addition (vcvarsXY.bat), however that is the only use case I have for that at the moment. Having a full fledged PS entry point to setting up an environment for invoking the compiler would serve me well. Not being able to create an x64 tool session is the only reason I still use Import-CmdEnvironment. Feel free to upvote my request on developercommunity.
Will there be any major improvements in 7.x regarding error handling, i.e. setting $? reliably requires $PSCmdlet.WriteError() and not Write-Error.
The documentation side of things is mostly covered by https://github.com/MicrosoftDocs/PowerShell-Docs/issues/1583.
Some extra links on the topic:
It would be nice if AZURE, Exchange Online, and Office365 were supported. Until then I will continue to use Windows PowerShell 5.1, and learn PowerShell 7.0 as I wait.
Great to hear there are plans to improve native command interaction. Now every time I need to pass quote (“) to ripgrep I do it wrong first… Also every time I need to use some git commands with pipelines I just switch to Git Bash (piping text usually works but messes up encoding sometimes, piping binary streams doesn’t work)
If only these two issuess would be resolved it would be a huge improvement.