Repository navigation
Allow enabling experimental features via env var #19256
Description
Summary of the new feature / enhancement
In CI, if someone wants to use an experimental feature, it currently is inconvenient to write to the powershell.config.json file before pwsh starts and then potentially set it back if the container instance is being reused. Instead, it would be convenient to have pwsh also read from a env var like POWERSHELL_EXPERIMENTAL_FEATURES which is a comma separated list of the names of experimental features to enable.
The env var would override powershell.config.json for experimental features.
Proposed technical implementation details (optional)
No response
Activity
iSazonov commentedon Mar 2, 2023
Maybe enhance Get-ExperimentalFeature cmdlet to generate the string for follow copy-paster.
kilasuit commentedon Mar 5, 2023
I don't see a problem with this, even though I don't like env vars and would rather not see more of them, I can see why implementing this would make a lot of sense in some cases
iSazonov commentedon Mar 5, 2023
Given the narrow purpose of this variable, I would suggest that it should be "hidden" with "__" prefix.
Once upon a time we breathed a sigh of relief when Registry appeared in Windows and replaced a huge number of configuration files and environment variables. The positive effect was terrific.
It's amazing to see that it's not being ported and there's not even a sign of it. :-(
krokofant commentedon Mar 6, 2023
Is there any chance that this could make it to a release of PowerShell 7.2? I'm very curious about how an upgrade path will be laid out so that PowerShell won't break CI system when the
PSNativeCommandArgumentPassingfeature is enabled by default on CI systems like Github actions.Being able to enable this feature on 7.2 via environment variable would make it easier to piece by piece migrate scripts to this feature...
SteveL-MSFT commentedon Mar 6, 2023
Emil Sundin (@krokofant) that's a good use case and something that could be considered since it's opt-in
daxian-dbw commentedon Mar 6, 2023
Can you please provide an example to show how inconvenient it is today?
Take Az Pipeline as an example, every
-pwsh: |step runs in a newpwshprocess, so you can set experimental features at the first-pwsh: |step, then the-pwsh: |steps after that will run in thepwshprocesses with that experimental feature enabled. In the end, the lastpwsh: |step can restore the experimental features, so the build agent will still have the original experimental feature settings.This doesn't seem very cumbersome to me ...
SteveL-MSFT commentedon Mar 7, 2023
Dongbo Wang (@daxian-dbw) container images get reused sometimes w/o resetting them, so you would need to backup the existing config, if the config is modified, you may want to retain those settings, so you would need to modify the config file rather than clobber it, then restore everything back. Certainly a worse case scenario, but this is exactly the scenario that was reported to me internally at Msft.
JamesWTruher commentedon Mar 8, 2023
the WG discussed this and weren't quite clear on the scenario, so a little elaboration would be helpful. We also suggested that a parameter to pwsh might be just as effective and reduce the expansion of the environment. There is also a concern about being able to remove the variable(s) from within PS (we think that the way dotnet removes environment variables is to just set them to an empty string, so clearing them from pwsh and then invokign might lead to ambiguity between no experimental features and use the standard config file.
If an environment variable approach was accepted, we also suggested that we should follow the
DOTNET_SettingNameHerefor each experimental feature (rather than a list)SteveL-MSFT commentedon Mar 13, 2023
A parameter on
pwshisn't as easily used in CI wherepwshis not called directly by the yaml. Within PS, you'd remove them as any env var by setting it to$null, so not sure how it's different here. Having individual env vars would be fine as well as long as experimental feature names don't allow for whitespace.krokofant commentedon Jul 3, 2023
As november is slowly approaching and with it .NET 8 release and PowerShell 7.4 LTS, can this be prioritized?
It would be very desirable to have an upgrade path before merging PowerShell 7.4 into Azure Pipelines/GitHub Action agents that has
PSNativeCommandArgumentPassingenabled by default.SteveL-MSFT commentedon Oct 9, 2023
Emil Sundin (@krokofant) unfortunately, 7.4 is on path for a release candidate, so we're not taking any more feature changes. This will show up in 7.5 at the earliest.
JamesWTruher commentedon Nov 27, 2023
The @PowerShell/wg-powershell-engine discussed this again and before committing engineering effort on this, we would like to have a good discussion on how this should work take place, especially with regard to interaction of environment variables with settings found in the
config.jsonfile. It has been an issue for us in the past, so having a discussion before the engineering takes place of the behavior would be prudent.microsoft-github-policy-service commentedon May 26, 2024
This issue has not had any activity in 6 months, if there is no further activity in 7 days, the issue will be closed automatically.
Activity in this case refers only to comments on the issue. If the issue is closed and you are the author, you can re-open the issue using the button below. Please add more information to be considered during retriage. If you are not the author but the issue is impacting you after it has been closed, please submit a new issue with updated details and a link to this issue and the original.