Powershell: Improve experience for side-by-side versions of PowerShell

[iSazonov]

We can setup multiple PowerShell Core versions on a system side-by-side (on Windows side-by-side with Windows PowerShell).
What about to enhance -Version to get better UX?

powershell -Version 5.1
powershell -Version 6.0.0
powershell -Version 6.0.0-Beta.4
powershell -Version UserDefault
powershell -Version SystemDefault

[SteveL-MSFT]

We would also need set-powershell and get-powershell cmdlets to set the default and enumerate installed versions. This should probably end up being an RFC.

cc @joeyaiello

[iSazonov]

We have so much defaults that the new cmdlets looks wasteful.
I expect that only developers will have multiple installed versions, users - Windows PowerShell and one-two PowerShell Core. Also system services (daemons) can use specific version. A distributive provider can include a PowerShell Core version as system default. An application provider can make the same.
They must all have a predictable way to run the correct version.
If Windows PowerShell stops on 5 version (5.1, 5.2, ..., 5.12 ..) we would use -Version to run a correct version - PowerShell Core starts with 6 version.

[SteveL-MSFT]

I agree that most users won't likely have more than one version of PSCore6 installed which is why this issue isn't High Priority for me. Current solution is to use the full path and advanced users will know what they are doing. Apps that distribute PSCore6.x will treat it as a library not should not be expected to be used by the end user. Some apps will be fine with any version of PSCore6 being available while others may have dependencies on specific versions for various reasons. Apps should not change the system default.

[iSazonov]

Main thought is that we should have simple possibility to switch default Windows and Core versions user-wide and system-wide.
Ideally PowerShell should take Version parameter and/or configuration option to run a desired version.

[joeyaiello]

Yeah, there's really two issues that need to be addressed here:

1. Shelling into Windows PowerShell vs. PowerShell Core. This one requires changes to Windows in some form or another, as Windows PowerShell needs to be aware of PowerShell Core's existence (system32 PATH wins over ProgramFiles PATH in the vast majority of cases). Unless we give powershell.exe an symbolic link in $PSHome for PS6 like ps6.exe, but that's a crappy band-aid I'd rather avoid.
2. Managing future side-by-side versions of PowerShell Core. I predict one day we might need something venv or rbenv, but not until at least 6.1.

I'm not sure we want to dive in on the former just yet, but it would ideally be addressed around (or just after) the "RTM" of PowerShell Core 6. The latter can wait.

[KirkMunro]

With PowerShell 7 offering LTS versions with a 3 year support cycle, some more discussions around SxS installations of PowerShell should be had soon so that if there are some changes that can be made in the current release timeframe, by the PS Team or the Community, there is time to do so. The notion of a 3 year support cycle without side-by-side support is a scary proposition.

Today we can install stable and preview side-by-side, but we need to consider supporting multiple stable versions installed side by side so that scripters can take hard dependencies on one LTS version of PowerShell without locking that machine down to that version for 3 years! Can we please talk about this _now_ and see what can be done so that management solutions can be built on the reliability of a LTS release without an unnecessary system lockdown to just that version during that time?

[SteveL-MSFT]

@KirkMunro do you have a specific proposal in mind? Current SxS support is via filepath. Is the desire to have something like pwsh -version 6.2.1?

[KirkMunro]

Yes, exactly that.

The management community is reticent to update management solutions. The development community moves forward much more quickly. I think we really need to consider a solution that allows management solutions to be maintained under LTS while not holding back additional solutions that leverage newer versions/functionality. This is especially important since PowerShell is interpreted and not compiled (we don't have the luxury of building independent executables from PowerShell that target different runtimes like a .NET developer has when building projects in C#, for example).

[SteveL-MSFT]

I would be ok with supporting pwsh -version x where x is one installed to a well known location on Windows, Linux, and macOS. All it would do is shell out to pwsh for that version. On Linux/macOS, we can use exec, but on Windows, you would have two pwsh processes. Would also need a way to enumerate installed versions. Seems like a RFC should be written for this.

[iSazonov]

Seems like a RFC should be written for this.

We already have #4836 with PowerShell Committee conclusion to have the RFC. It was frozen
at that time since side-by-side feature was not stable.

[KirkMunro]

Do you want to push that forward then @iSazonov? If not, I'm happy to write the RFC but I don't want to take that away from you if you've already put thought into it. This needs to be done soon though to take advantage of the opportunity to get this done during the PS7 cycle. If I don't write it I'll definitely review it and share my thoughts.

[iSazonov]

@KirkMunro It is not easy for me to write large text (but a high quality) on non-native language. Feel free to pull the RFC. Many thanks!

(It seems I keep a branch with the enumerating version prototype since then #4836 :-) It was ported from VS Code(!) )

[KirkMunro]

Here: https://github.com/PowerShell/PowerShell-RFC/pull/202. Please let me know what you think @iSazonov and @SteveL-MSFT.

[archmangler]

Hi

May I ask about the progress of this?

We have a use-case for this: it is to switch between pwsh versions within our docker deployment container which serves multiple applications and which needs to support multiple pwsh versions (with their specific combination of powershell cmdlets and modules).

If we had something like virtualenv/venv available it would help a lot.

[iSazonov]

which needs to support multiple pwsh versions

@archmangler Really there are two main version - Windows PowerShell and PowerShell 7.0, and no needs to have more installed versions. If your scenario is more specific please open new issue to discuss.