You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Maintain user-level experimental-feature configuration separately for preview and stable versions #14891
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.
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.
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?
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.
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.
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.
Reacted by Travis Plunk
microsoft-github-policy-service commented on Nov 16, 2023
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.
microsoft-github-policy-service commented on Nov 16, 2023
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.
Activity
vexx32 commentedon Mar 31, 2022
/cc Jason Helmick (@theJasonHelmick)
rkeithhill commentedon Apr 2, 2022
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.
theJasonHelmick commentedon Apr 4, 2022
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
DisabledPreviewExperimentalFeaturesthat 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?doctordns commentedon Apr 5, 2022
i would have expected the JSON to list ALL the experimental features and whether enabled or disabled.
daxian-dbw commentedon Apr 5, 2022
Jason Helmick (@theJasonHelmick) I would like you to also consider having preview versions use a different path for the current-user scope
powershell.config.jsonfile.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 beC:\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
$PSHOMEfor each pwsh instance, so there is no conflict on it.daxian-dbw commentedon Apr 5, 2022
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.
theJasonHelmick commentedon Apr 5, 2022
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)?
daxian-dbw commentedon Apr 5, 2022
Jason Helmick (@theJasonHelmick) Do we support MU for preview releases?
theJasonHelmick commentedon Apr 6, 2022
Dongbo Wang (@daxian-dbw) Travis Plunk (@TravisEz13) - Yes, we have been.
daxian-dbw commentedon Apr 6, 2022
The current-user scope configuration file doesn't come with PowerShell package. It's created by user (explicitly, or via
Enable-ExperimentalFeaturecommand), so I don't think this will affect MU.microsoft-github-policy-service commentedon Nov 16, 2023
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.
microsoft-github-policy-service commentedon Nov 16, 2023
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.
microsoft-github-policy-service commentedon Nov 23, 2023
This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.