Show what experimental features are turned on at the start of interactive sessions

Summary of the new feature/enhancement

For an interactive PowerShell user it is important to know if and what experimental features are currently enabled - if any.

In a stable / LTS version, the expectation may be that NONE are enabled, so if any are, it's helpful to be notified.
- Experimental features may inadvertently be enabled, namely if, in a previously installed or side-by-side preview version features were ever selectively enabled or disabled with -Scope CurrentUser - which is the default scope. The resulting "$(Split-Path $PROFILE.CurrentUserAllHosts)/powershell.config.json" file takes effect for all installed versions, and overrides "PSHOME/powershell.config.json"
In preview versions - which by default come with all experimental features enabled - it is additionally important to know which ones are not enabled in a given session, since, after using selective disabling, newly introduced features may end up DISABLED in preview versions installed later (as explained above).
- Additionally, showing in effect all experimental features helps with discovering new ones.

Proposed technical implementation details (optional)

Update: See the alternative, less verbose proposal below.

On entering an interactive session, show something like the following:

For PREVIEW versions:

Show both the enabled and disabled experimental features, grouped by state:

@"
PowerShell 7.2.0-preview.3
Copyright (c) Microsoft Corporation.

https://aka.ms/powershell
Type 'help' to get help.

ENABLED experimental features:
  $((Get-ExperimentalFeature | Where-Object -not Enabled).Name)
DISABLED experimental features:
  $((Get-ExperimentalFeature | Where-Object Enabled).Name)
"@

It would additionally be helpful if features added since the previous stable release could be highlighted.

For STABLE / LTS versions:

Show only enabled experimental features (if any - see @rkeithhill's more sophisticated version).

@"
PowerShell 7.2.0-preview.3
Copyright (c) Microsoft Corporation.

https://aka.ms/powershell
Type 'help' to get help.

Enabled experimental features (type 'help about_experimental_features' for help):
  $((Get-ExperimentalFeature | Where-Object -not Enabled).Name)
"@

As @DHowett notes, all this extra text should be considered part of the "logo" and should therefore be suppressed if -NoLogo is passed to the CLI.

Or maybe this for stable:

& {$OFS = ', '; @"
PowerShell 7.2.0
Copyright (c) Microsoft Corporation.

https://aka.ms/powershell
$($exp = Get-ExperimentalFeature | Where-Object -not Enabled
  $exp ? 
    "`nEnabled Experimental features:`n  $($exp.Name)`n`nType 'help' to get help. Type 'help about_experimental_features' to get help on experimental features." : 
    "Type 'help' to get help."
  )

"@}

Outputs this:

PowerShell 7.2.0
Copyright (c) Microsoft Corporation.

https://aka.ms/powershell

Enabled Experimental features:
  PSCultureInvariantReplaceOperator, PSImplicitRemotingBatching, PSNotApplyErrorActionToStderr, PSSubsystemPluginModel, Microsoft.PowerShell.Utility.PSManageBreakpointsInRunspace, PSDesiredStateConfiguration.InvokeDscResource

Type 'help' to get help. Type 'help about_experimental_features' to get help on experimental features.

02-20 13:06:26 49>

or this:

PowerShell 7.2.0
Copyright (c) Microsoft Corporation.

https://aka.ms/powershell
Type 'help' to get help.

02-20 13:07:04 50>

If we commit to this, I'd really hope that it's suppressed by -NoLogo.

Dustin L. Howett (@DHowett)

I wish GitHub had more reaction emojis. I'd like to 💯 Dustin L. Howett (@DHowett)'s comment above. :-)

Dustin L. Howett (@DHowett)

I appreciate both suggestions. Dustin L. Howett (@DHowett), I've noted your suggestion in the OP; Keith Hill (@rkeithhill), I've linked to your improved command from the OP.

This will rather annoy users as it does with the new version notification and the large logo (we already have such issues).
It would make sense as a one-time function of the installer to show release notes and turned on experimental features.

It would make sense as a one-time function of the installer

I like that idea separately - it's not one or the other.

Given that not everyone uses official installers, that information is better shown in the terminal on first startup (unless suppressed with -NoLogo). This should probably be a separate proposal.

This will rather annoy users as it does with the new version notification

One person's annoyance is another person's feature.

As in the version notification case, to me the sensible default behavior is to show this information, while given users an opt-out - as we have done via the POWERSHELL_UPDATECHECK environment variable.

As for how much of an annoyance it would be:

In stable versions (including LTS):
- You wouldn't see a notification under normal circumstances, because if you want the official, stable environment, you shouldn't have experimental features turned on.
- If they're turned on accidentally, you'll probably fix that problem there and then, and the notification will go away.
- Conversely, if turning them on was intentional, the notification is a good reminder to have that the behavior of the session will be nonstandard.
In preview versions:
- Preview users are a self-selecting demographic to be begin with: someone who installs a preview version is prepared to deal with being inconvenienced - through possible instability alone - for the sake of getting a preview of functionality to come.
- Since experimental features are an important part of preview versions - and may indeed be the reason someone installs a preview version to begin with - having reminders of what's turned on and what is not is helpful.

I suppose one way to reduce the amount of information shown is that if all experimental features are enabled, to only state that in the abstract, rather than enumerating all the feature names.

Joey Aiello (@joeyaiello)

/cc Joey Aiello (@joeyaiello) Jason Helmick (@theJasonHelmick) to comment.

I'm really not in favor of a bunch of blather on the screen when I start the shell. I can easily find out what experimental features are enabled. If you need this personally, it's very easy to add it to your profile, but I don't believe you've made the argument sufficiently to enable this for all users every time the shell starts.

I don't believe you've made the argument sufficiently

The OP argues specific points, separately for stable and preview versions, including the point that in stable versions you normally wouldn't see additional information and that if something is shown it is important to show it, and that in preview versions you'd want to know which are and are not enabled.

Which of these arguments do you think are insufficient, and why?

With respect to the amount of extra information shown, one way to reduce it is to apply exception logic, that is to effectively issue an abstract warning if the configuration is unusual, namely:

In a stable version, if at least one experimental feature is enabled, say something like:
- WARNING: At least one experimental feature is in enabled. Type 'help about_experimental_features' for help.
In a preview version, where all features are enabled by default, warn if at least one experimental feature is disabled:
- WARNING: At least one experimental feature is in disabled. Type 'help about_experimental_features' for help.

In practice, I suspect such warnings would rarely show if we stopped sharing user-level configuration files across side-by-side versions and if we reversed the exclusion logic for preview versions. Currently, it is very easy to unwittingly enable or disable experimental features - see #14891.

For preview versions I would prefer something short and sweet, such as:

PowerShell 7.4.0-preview.1 (Experimental features enabled. Use 'Get-ExperimentalFeature' for info.)

Anything regarded as being a logo should be limited to one line. Anything longer should be considered a notice. A runonce notice that lists experimental features, would be appropriate for new version installations. Something like:

"`n`e[45;97mNOTE: Powershell has been upgraded from v7.3.2 to v7.4.0. Below is a list of experimental features in the new version. Use Get-ExperimentalFeature to view this list again. See https://github.com/PowerShell/PowerShell/releases/tag/v7.4.0-preview.1 for release notes.`e[0m"
Get-ExperimentalFeature

Ilya (@iSazonov)

Taking into consideration all comments in this thread, but especially pointing out both of Ilya (@iSazonov) & James Truher (@JamesWTruher) comments & other issues around the logo text what is suggested by Andrew74L above is almost what I think many in the community would overall deem reasonable. That said I think for others that may want a fuller output similar to what Keith Hill (@rkeithhill) show'd above, so I am raising some additional issues to discuss this and gain further feedback

Michael Klement (@mklement0)

Michael Klement (@mklement0) - Thank you for this suggestion. The working group believes that running Get-ExperimentalFeature is the appropriate way to determine this information.

That is disappointing.

As an example of the confusion that ensues when users aren't aware of what experimental features are in effect, especially when it changes fundamental behaviors, see #18944

Such a short answer from WG explains nothing and gives no insight.
Actually the question was how best to inform users what's new.
Such a feeling that every member of WG said that he personally does not need it because he already knows everything. 😄

Although this question of "how best to tell users what's new" comes up all the time in different ways - not just about experimental features, but about breaking changes too.

Although this question of "how best to tell users what's new" comes up all the time in different ways - not just about experimental features, but about breaking changes too.

Could the logo... PowerShell 7.3.2 ...be a hyperlink?

Although this question of "how best to tell users what's new" comes up all the time in different ways - not just about experimental features, but about breaking changes too.

Could the logo... PowerShell 7.3.2 ...be a hyperlink?

Some terminals support this.
Although I see that users rather prefer not to have a logo. So we are left to consider only the option of a one-time display of information on the first startup. That's what VS Code does after an upgrade, for example.

Ilya (@iSazonov)

Although I see that users rather prefer not to have a logo. So we are left to consider only the option of a one-time display of information on the first startup. That's what VS Code does after an upgrade, for example.

Ilya (@iSazonov) Can you please open a new issue describing this idea? Comparing with changing the startup logo, I think it's a better way to improve the user awareness of the changes in the shell. Please mark it to be reviewed by the "interactive-console" WG.

Dongbo Wang (@daxian-dbw)

Dongbo Wang (@daxian-dbw) / Ilya (@iSazonov) I have added it into this meta issue that I've got for tracking comments about logo/nologo which is already marked for Interactive-console WG

Navigation Menu

Repository navigation

Show what experimental features are turned on at the start of interactive sessions #14862

Summary of the new feature/enhancement

Proposed technical implementation details (optional)

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Show what experimental features are turned on at the start of interactive sessions #14862

Description

Summary of the new feature/enhancement

Proposed technical implementation details (optional)

Activity

rkeithhill commented on Feb 20, 2021

DHowett commented on Feb 22, 2021

rkeithhill commented on Feb 22, 2021

mklement0 commented on Feb 22, 2021

iSazonov commented on Feb 22, 2021

mklement0 commented on Feb 22, 2021

daxian-dbw commented on Feb 22, 2021

JamesWTruher commented on Feb 23, 2021

mklement0 commented on Feb 23, 2021

mklement0 commented on Feb 23, 2021

Andrew74L commented on Jan 26, 2023

kilasuit commented on Jan 28, 2023

theJasonHelmick commented on Feb 8, 2023

mklement0 commented on Feb 10, 2023

iSazonov commented on Feb 10, 2023

Andrew74L commented on Feb 10, 2023

iSazonov commented on Feb 10, 2023

daxian-dbw commented on Feb 13, 2023

kilasuit commented on Feb 13, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions