Skip to content

Improve experience for side-by-side versions of PowerShell #4199

Closed
Closed
Improve experience for side-by-side versions of PowerShell#4199
Labels
Area-SideBySiderelated to ability to run PS7 side-by-side with WinPS or different versions of PS7Issue-Discussionthe issue may not have a clear classification yet. The issue may generate an RFC or may be reclassif

Description

@iSazonov
Ilya (iSazonov)
opened on Jul 7, 2017

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

Activity

  1. Ilya (iSazonov)
    added
    Area-SideBySiderelated to ability to run PS7 side-by-side with WinPS or different versions of PS7
    Issue-Discussionthe issue may not have a clear classification yet. The issue may generate an RFC or may be reclassif
    on Jul 7, 2017
  2. Steve Lee (SteveL-MSFT)
    changed the title [-]Enhance '-Version'[/-] [+]Improve experience for side-by-side versions of PowerShell[/+] on Jul 7, 2017

  3. SteveL-MSFT commented on Jul 7, 2017

    @SteveL-MSFT
    Steve Lee (SteveL-MSFT)
    on Jul 7, 2017
    Member

    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 Joey Aiello (@joeyaiello)

  4. iSazonov commented on Jul 8, 2017

    @iSazonov
    Ilya (iSazonov)
    on Jul 8, 2017
    CollaboratorAuthor

    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.

  5. SteveL-MSFT commented on Jul 9, 2017

    @SteveL-MSFT
    Steve Lee (SteveL-MSFT)
    on Jul 9, 2017
    Member

    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.

  6. iSazonov commented on Jul 9, 2017

    @iSazonov
    Ilya (iSazonov)
    on Jul 9, 2017
    CollaboratorAuthor

    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.

  7. joeyaiello commented on Jul 10, 2017

    @joeyaiello
    Joey Aiello (joeyaiello)
    on Jul 10, 2017
    Contributor

    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.

  8. KirkMunro commented on Jun 20, 2019

    @KirkMunro
    Kirk Munro (KirkMunro)
    on Jun 20, 2019
    Contributor

    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?

  9. SteveL-MSFT commented on Jun 20, 2019

    @SteveL-MSFT
    Steve Lee (SteveL-MSFT)
    on Jun 20, 2019
    Member

    Kirk Munro (@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?

  10. KirkMunro commented on Jun 20, 2019

    @KirkMunro
    Kirk Munro (KirkMunro)
    on Jun 20, 2019
    Contributor

    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).

  11. SteveL-MSFT commented on Jun 20, 2019

    @SteveL-MSFT
    Steve Lee (SteveL-MSFT)
    on Jun 20, 2019
    Member

    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.

  12. iSazonov commented on Jun 21, 2019

    @iSazonov
    Ilya (iSazonov)
    on Jun 21, 2019
    CollaboratorAuthor

    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.

  13. KirkMunro commented on Jun 21, 2019

    @KirkMunro
    Kirk Munro (KirkMunro)
    on Jun 21, 2019
    Contributor

    Do you want to push that forward then Ilya (@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.

  14. iSazonov commented on Jun 21, 2019

    @iSazonov
    Ilya (iSazonov)
    on Jun 21, 2019
    CollaboratorAuthor

    Kirk Munro (@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(!) )

  15. KirkMunro commented on Jun 21, 2019

    @KirkMunro
    Kirk Munro (KirkMunro)
    on Jun 21, 2019
    Contributor

    Here: PowerShell/PowerShell-RFC#202. Please let me know what you think Ilya (@iSazonov) and Steve Lee (@SteveL-MSFT).

  16. archmangler commented on May 5, 2020

    @archmangler
    Traiano Welcome (archmangler)
    on May 5, 2020

    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.

  17. iSazonov commented on May 5, 2020

    @iSazonov
    Ilya (iSazonov)
    on May 5, 2020
    CollaboratorAuthor

    which needs to support multiple pwsh versions

    Traiano Welcome (@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.

  18. Ilya (iSazonov)
    closed this as completedon May 25, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Area-SideBySiderelated to ability to run PS7 side-by-side with WinPS or different versions of PS7Issue-Discussionthe issue may not have a clear classification yet. The issue may generate an RFC or may be reclassif

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions