Skip to content

Maintain user-level experimental-feature configuration separately for preview and stable versions #14891

Closed

Description

Related: #14862

Summary of the new feature/enhancement

Currently, selective enabling or disabling experimental features at the user level (-Scope CurrentUser, which is the default) takes effect for all side-by-side PowerShell (Core) installations, irrespective of whether they're stable versions or preview versions.

This can unwittingly result in the following scenario:

  • By selectively disabling an experimental feature in a preview version, you're implicitly enabling experimental features for side-by-side stable versions, because the same powershell.config.json file is used by all side-by-side version, and because disabling is based on excluding the disabled feature from the list of explicitly enumerated enabled features in that file (based on the all-enabled starting point in preview versions).

The state of experimental features for preview versions should be managed separately from stable versions.


An additional question is how to handle cross-preview-version configuration:

  • Say you disable an experimental feature in a preview version (where all features are enabled by default).

  • You later install a new preview version that comes with new experimental features.

  • With a version-agnostic configuration, it isn't just the previously explicitly disabled feature that ends up disabled, but all newly added ones as well.

Proposed implementation:

Introduce a new property in the user-level powershell.config.json file:

  • named something like DisabledPreviewExperimentalFeatures, which is only read by preview versions, instead of the ExperimentalFeatures property.

  • whose logic is the inverse of ExperimentalFeatures: all features except the ones listed should then be enabled.

Written as of PowerShell Core 7.2.0-preview.3

Activity

  1. vexx32 commented on Mar 31, 2022

    @vexx32
    Collaborator
  2. rkeithhill commented on Apr 2, 2022

    @rkeithhill
    Collaborator

    The Engine WG discussed this yesterday and agree that it's a reasonable ask. There needs to be discussion on a better implementation. We cc'd Jason for his input on this.

  3. theJasonHelmick commented on Apr 4, 2022

    @theJasonHelmick
    Collaborator

    I would agree that this seems like a responsible request. I'm not convinced that this problem needs to be addressed, although cumbersome. I do think it's certainly worth discussing and investigating further - along with other customization options that have been discussed and how to handle powershell.config.json.

    So, help me clarify the suggestion. The suggestion is to add DisabledPreviewExperimentalFeatures that requires a user to individually list the features that are to be disabled. If they don't list them, then all experimental features are enabled for this and all previews. Is that correct?

  4. doctordns commented on Apr 5, 2022

    @doctordns
    Collaborator

    i would have expected the JSON to list ALL the experimental features and whether enabled or disabled.

  5. daxian-dbw commented on Apr 5, 2022

    @daxian-dbw
    Member

    Jason Helmick (@theJasonHelmick) I would like you to also consider having preview versions use a different path for the current-user scope powershell.config.json file.

    Take windows as an example. Today, the current-user scope file is always located in C:\Users\<user-name>\Documents\PowerShell\powershell.config.json. So, maybe for preview versions, the current-user scope file path should be C:\Users\<user-name>\Documents\PowerShell\preview\powershell.config.json.

    With this, the stable and preview versions of pwsh uses different current-user scope config files, and won't be conflicting with each other. For the all-user scope config files, they are always in $PSHOME for each pwsh instance, so there is no conflict on it.

  6. daxian-dbw commented on Apr 5, 2022

    @daxian-dbw
    Member

    Thomas Lee (@doctordns) Consider there may be non-PowerShell-built-in modules in the module path that define experimental features, it's not possible to list all experimental features until at PowerShell run time.

  7. theJasonHelmick commented on Apr 5, 2022

    @theJasonHelmick
    Collaborator

    Dongbo Wang (@daxian-dbw) Certainly makes sense to separate the previews from stable with different paths to the json. I'm wondering if this impacts MU Travis Plunk (@TravisEz13)?

  8. daxian-dbw commented on Apr 5, 2022

    @daxian-dbw
    Member

    Jason Helmick (@theJasonHelmick) Do we support MU for preview releases?

  9. theJasonHelmick commented on Apr 6, 2022

    @theJasonHelmick
    Collaborator
  10. daxian-dbw commented on Apr 6, 2022

    @daxian-dbw
    Member

    The current-user scope configuration file doesn't come with PowerShell package. It's created by user (explicitly, or via Enable-ExperimentalFeature command), so I don't think this will affect MU.

  11. microsoft-github-policy-service commented on Nov 16, 2023

    @microsoft-github-policy-service
    Contributor

    This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.

  12. microsoft-github-policy-service commented on Nov 16, 2023

    @microsoft-github-policy-service
    Contributor

    This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.

  13. microsoft-github-policy-service commented on Nov 23, 2023

    @microsoft-github-policy-service
    Contributor

    This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

Issue-Enhancementthe issue is more of a feature request than a bugResolution-No ActivityIssue has had no activity for 6 months or moreWG-Enginecore PowerShell engine, interpreter, and runtime

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions