Closed cottsay closed 1 month ago
Also discussed offline:
The is_feature_flag_set
now logs a warning the first time an enabled feature is queried. It will look like this on the console:
[0.208s] colcon.colcon_core.feature_flags WARNING Enabling feature: foobar
I'd rather not directly write to stdout
or stderr
, and INFO
level log messages are not printed to the console by default, so this seemed like the best move. A warning also highlights the possible instability of the feature's use.
I'd rather not directly write to
stdout
orstderr
, andINFO
level log messages are not printed to the console by default, so this seemed like the best move. A warning also highlights the possible instability of the feature's use.
I think warning is appropriate since feature flags are used to change default behavior in inherently unstable and under-tested ways (i.e. we will never test with the complete cartesian product of feature flag values).
Attention: Patch coverage is 96.29630%
with 1 lines
in your changes are missing coverage. Please review.
Project coverage is 83.33%. Comparing base (
485f500
) to head (6edd2b5
). Report is 1 commits behind head on master.
Files | Patch % | Lines |
---|---|---|
colcon_core/feature_flags.py | 96.00% | 0 Missing and 1 partial :warning: |
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
The intended use for colcon feature flags is to ship pre-production and prototype features in a disabled state, which can be enabled by specifying a particular environment variable value. By using an environment variable, these possibly dangerous or unstable features are hidden from common users but are enabled in a way which can be audited.
Current examples of possible uses:
colcon test
(#571)colcon-python-project
prototype