Feature flags #4940

ridiculousfish · 2018-04-25T00:25:50Z

This is my proposal for feature flags, as a mechanism for introducing breaking changes ("features"). This may include removing existing syntax, or introducing new incompatible syntax.

Feature flags are set at startup via the command line and variables (environment or universal), and cannot be changed after: you have to make a new session. They can be queried at any point in the code. Features are also grouped. For example, we would have a "3.0" group for features introduced in 3.0; this lets authors test for 3.0 compatibility in one go. The "all" group is bleeding edge.

Feature flags are only intended to be used for transitions. The "off" state is the old behavior, the "on" state is the new behavior, and in a few releases we'll remove support for running with the feature off. They are not a long-term configuration mechanism.

This is how we would use feature flags to introduce a breaking change:

Add a feature flag entry. This entry contains a short feature name, and one or more group names. For example, the feature stderr-nocaret is in group 3.0. The feature defaults to off, but we'll publish the upcoming change, and its feature flag name.
Script authors can test their script against the new feature by passing it on the command line: fish --features stderr-nocaret or fish --features 3.0
Users can opt into new features by setting a universal variable. set -U fish_features stderr-nocaret.
status can be used to list features, and check if they are on or off (should rarely be necessary).
After a bake-in period, we'll switch the default to on. During this period the feature can still be disabled: fish --features no-stderr-nocaret.
After another period, we'll remove support for the old behavior outright, and mark the feature as archived (still testable, but no longer reported).

All functions and completions that ship with fish need to be compatible with any feature combination, as much as is possible.

This PR introduces the feature flag mechanism, and adds a feature flag for the stderr-nocaret behavior, defaulting to off. That is, carets are still redirections, but users can opt into the new behavior where carets are ordinary characters.

This PR contains the machinery and some tests. I'm eager to hear feedback on this approach before moving forwards with docs, etc.

faho · 2018-04-25T13:44:05Z

This sounds like a brilliant idea, and I'd love it for % and ? as well for 3.0.

status being hooked up would allow e.g. deprecating . for source this way, as it's a pure-script feature.

I don't think we need to do it for any of the other changes.

Would it be possible to add a link to further documentation to the description? Or hook it up to help, so you'd do help feature std-noerr or something, and that gives you a paragraph or so explaining the change?

faho · 2018-04-25T13:37:51Z

src/future_feature_flags.h

+        features_t::flag_t flag;
+
+        /// User-presentable short name of the feature flag.
+        const wchar_t *name;


Any reason these are wchar_t instead of wcstring?

There will be string literals, so it's a little cheaper to initialize since it can be in a read-only segment, and doesn't need malloc().

faho · 2018-04-25T21:27:04Z

I'd love it for % and ? as well for 3.0.

One issue with ? specifically though is that we'd have to jump through hoops to make e.g. our git completions work in both modes, because there's no nice way to make a case that matches just a literal ?? in both.

The best I can come up with is set -l dq '??' and later case "$dq".

Also can fish -n be taught about this?

zanchey · 2018-04-29T14:44:43Z

If I'm distributing a fish script, is there a way for me to set the feature flags I want for my script? The shebang line isn't much good because only the first argument is useful.

faho · 2018-04-29T17:47:19Z

If I'm distributing a fish script, is there a way for me to set the feature flags I want for my script?

If I'm understanding @ridiculousfish correctly, the idea is that you wouldn't - if you're touching the script, you should just port it to where it doesn't need "feature" flags (I think "compatibility" flags might be a better name) instead of adding any flags - that would become obsolete soon.

ridiculousfish · 2018-04-29T21:07:34Z

Yeah that's the hope. Ideally writing a script that works on multiple versions is not hard. If it is hard then the features were badly designed.

ridiculousfish · 2018-04-29T21:19:12Z

One issue with ? specifically though is that we'd have to jump through hoops to make e.g. our git completions work in both modes, because there's no nice way to make a case that matches just a literal ?? in both.

Nice spotting. This is annoying enough that we should just continue to support '?' in all cases. That is, '\?' will always be a literal ? regardless of whether ? is a glob. This feels harmless to me.

Also can fish -n be taught about this?

What did you have in mind? The feature flags don't make any particular syntax an error, they just change its meaning.

faho · 2018-04-29T21:37:56Z

That is, '?' will always be a literal ? regardless of whether ? is a glob.

That might be surprising when it comes to regexes - ? has a special meaning there as well.

I'd rather just case do that, for the time being.

What did you have in mind?

Warn when one of these features is used.

E.g. with the following script:

somecommand ^/dev/null

run fish -n or maybe fish -n --features stderr-nocaret on it, and get:

"Line XY: Use of "^" where it would mean stderr
somecommand ^/dev/null
                        ^

as a sort of static analysis to aid in porting away from deprecated features.

See e.g. #4950 - we didn't catch the remaining caret redirection because it had a space, and I think all of us just used ad-hoc regexes to check for them.

This introduces a new type features_t that exposes feature flags. The intent is to allow a deprecation/incremental adoption path. This is not a general purpose configuration mechanism, but instead allows for compatibility during the transition as features are added/removed. Each feature has a user-presentable short name and a short description. Their values are tracked in a struct features_t. We start with one feature stderr_nocaret, but it's not hooked up yet.

This teaches the status command to work with features. 'status features' will show a table listing all known features and whether they are currently on or off. `status test-feature` will test an individual feature, setting the exit status to 0 if the feature is on, 1 if off, 2 if unknown.

This introduces a new command line option --features which can be used for enabling or disabling features for a particular fish session. Examples: fish --features stderr-nocaret fish --features 3.0,no-stderr-nocaret fish --features all Note that the feature set cannot be changed in an existing session.

This partially reverts 5b489ca, with carets acting as redirections unless the stderr-nocaret flag is set. This flag is off by default but may be enabled on the command line: fish --features stderr-nocaret

This enables users to opt in (or out) of specific features by setting the fish_features environment variable. For example `set -U fish_features stderr-nocaret` to opt into removing the caret redirection.

This adds a feature flag for controlling whether question marks are globs. It is not yet hooked up.

This partially reverts 6e56637 and fish-shell#4520 by bringing back the ? wildcard, guarded by the qmark-noglob feature flag.

This is a convenience over fish_features().test()

Replace these with 2>

This merges support for feature flags. Closes fish-shell#4940

faho reviewed Apr 25, 2018

View reviewed changes

faho added enhancement RFC labels Apr 29, 2018

faho mentioned this pull request May 5, 2018

function: restore '%self' functionality for --on-process-exit #4952

Closed

ridiculousfish force-pushed the futurefeatures branch from 9ebc215 to bd352d6 Compare May 6, 2018 02:38

ridiculousfish added 11 commits May 6, 2018 11:20

Bring back caret redirections under a feature flag

902af26

This partially reverts 5b489ca, with carets acting as redirections unless the stderr-nocaret flag is set. This flag is off by default but may be enabled on the command line: fish --features stderr-nocaret

Set features from the environment

d3201ad

This enables users to opt in (or out) of specific features by setting the fish_features environment variable. For example `set -U fish_features stderr-nocaret` to opt into removing the caret redirection.

Add a qmark-noglob feature flag

dc8d603

This adds a feature flag for controlling whether question marks are globs. It is not yet hooked up.

Feature flag support for ? wildcard

762c31b

This partially reverts 6e56637 and fish-shell#4520 by bringing back the ? wildcard, guarded by the qmark-noglob feature flag.

Add a feature_test() function

4194b4e

This is a convenience over fish_features().test()

Remove some references to ^ redirection from the docs

87eb073

Replace these with 2>

Add future feature flags to the documentation

d623ac5

Changelog feature flags

060643a

ridiculousfish added a commit to ridiculousfish/fish-shell that referenced this pull request May 6, 2018

Merge branch 'futurefeatures'

aba69ac

This merges support for feature flags. Closes fish-shell#4940

ridiculousfish force-pushed the futurefeatures branch from bd352d6 to 060643a Compare May 6, 2018 19:47

ridiculousfish merged commit 060643a into fish-shell:master May 6, 2018

faho mentioned this pull request May 8, 2018

Remove caret (^) as redirector for stderr #4394

Closed

zanchey added this to the fish-3.0 milestone Sep 26, 2018

ridiculousfish deleted the futurefeatures branch December 13, 2019 03:53

github-actions bot locked as resolved and limited conversation to collaborators Apr 16, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Feature flags #4940

Feature flags #4940

ridiculousfish commented Apr 25, 2018 •

edited

Loading

faho commented Apr 25, 2018

faho Apr 25, 2018

ridiculousfish Apr 25, 2018

faho commented Apr 25, 2018

zanchey commented Apr 29, 2018

faho commented Apr 29, 2018

ridiculousfish commented Apr 29, 2018

ridiculousfish commented Apr 29, 2018

faho commented Apr 29, 2018

Feature flags #4940

Feature flags #4940

Conversation

ridiculousfish commented Apr 25, 2018 • edited Loading

faho commented Apr 25, 2018

faho Apr 25, 2018

Choose a reason for hiding this comment

ridiculousfish Apr 25, 2018

Choose a reason for hiding this comment

faho commented Apr 25, 2018

zanchey commented Apr 29, 2018

faho commented Apr 29, 2018

ridiculousfish commented Apr 29, 2018

ridiculousfish commented Apr 29, 2018

faho commented Apr 29, 2018

ridiculousfish commented Apr 25, 2018 •

edited

Loading