-
Notifications
You must be signed in to change notification settings - Fork 749
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: change tracing-subscriber
dependencies to enable std
#1659
Conversation
## Motivation Currently, some `tracing-subscriber` dependencies in other crates use `default-features = false`, to ensure that unneeded default features of `tracing-subscriber` are not inadvertently enabled. However, some of the features those crates enable also require the `std` feature flag. The `default-features = false` config _disables_ the `std` feature, so the required features are not available. ## Solution This branch changes those crates' dependencies on `tracing-subscriber` to also enable the `std` feature. ## Alternatives As an alternative solution, we could change `tracing-subscriber`'s feature flags so that features that require the standard library _also_ enable the `std` feature, rather than having those features _require_ it. I think this _might_ actually provide a better experience for most users.
## Motivation Currently, some `tracing-subscriber` dependencies in other crates use `default-features = false`, to ensure that unneeded default features of `tracing-subscriber` are not inadvertently enabled. However, some of the features those crates enable also require the `std` feature flag. The `default-features = false` config _disables_ the `std` feature, so the required features are not available. ## Solution This branch changes `tracing-subscriber`'s `fmt`, `registry`, and `env-filter` feature flags to also enable the `std` feature flag automatically. ## Alternatives As an alternative solution, we could change crates that depend on `tracing-subscriber` with `default-features = false` to also explicitly ensure that the `std` feature is enabled (which might be worth doing regardless). This is what PR #1659 does. However, I think the approach in this branch is more correct; the feature flags that require standard library support should automatically enable it. This provides a better experience for most users, who are simply adding `default-features = false` in order to avoid enabling un-needed features, not to support `no_std`, and would like enabling a feature flag to *actually* enable that feature. `no_std` users will know not to enable `registry`, `fmt`, and `env-filter` because the documentation notes that those features require the standard library.
## Motivation Currently, some `tracing-subscriber` dependencies in other crates use `default-features = false`, to ensure that unneeded default features of `tracing-subscriber` are not inadvertently enabled. However, some of the features those crates enable also require the `std` feature flag. The `default-features = false` config _disables_ the `std` feature, so the required features are not available. ## Solution This branch changes `tracing-subscriber`'s `fmt`, `registry`, and `env-filter` feature flags to also enable the `std` feature flag automatically. ## Alternatives As an alternative solution, we could change crates that depend on `tracing-subscriber` with `default-features = false` to also explicitly ensure that the `std` feature is enabled (which might be worth doing regardless). This is what PR #1659 does. However, I think the approach in this branch is more correct; the feature flags that require standard library support should automatically enable it. This provides a better experience for most users, who are simply adding `default-features = false` in order to avoid enabling un-needed features, not to support `no_std`, and would like enabling a feature flag to *actually* enable that feature. `no_std` users will know not to enable `registry`, `fmt`, and `env-filter` because the documentation notes that those features require the standard library.
#1660 also fixes the actual issue, but we should maybe merge this anyway for explicitness sake? |
That makes sense to me. 👍
I don't expect that the explicitness is benefitial, since presumably the other features which now transitively enable std are the features that |
Hmm, yeah, that's a good point. Going to just close this one, then! |
## Motivation Currently, some `tracing-subscriber` dependencies in other crates use `default-features = false`, to ensure that unneeded default features of `tracing-subscriber` are not inadvertently enabled. However, some of the features those crates enable also require the `std` feature flag. The `default-features = false` config _disables_ the `std` feature, so the required features are not available. ## Solution This branch changes `tracing-subscriber`'s `fmt`, `registry`, and `env-filter` feature flags to also enable the `std` feature flag automatically. ## Alternatives As an alternative solution, we could change crates that depend on `tracing-subscriber` with `default-features = false` to also explicitly ensure that the `std` feature is enabled (which might be worth doing regardless). This is what PR #1659 does. However, I think the approach in this branch is more correct; the feature flags that require standard library support should automatically enable it. This provides a better experience for most users, who are simply adding `default-features = false` in order to avoid enabling un-needed features, not to support `no_std`, and would like enabling a feature flag to *actually* enable that feature. `no_std` users will know not to enable `registry`, `fmt`, and `env-filter` because the documentation notes that those features require the standard library.
## Motivation Currently, some `tracing-subscriber` dependencies in other crates use `default-features = false`, to ensure that unneeded default features of `tracing-subscriber` are not inadvertently enabled. However, some of the features those crates enable also require the `std` feature flag. The `default-features = false` config _disables_ the `std` feature, so the required features are not available. ## Solution This branch changes `tracing-subscriber`'s `fmt`, `registry`, and `env-filter` feature flags to also enable the `std` feature flag automatically. ## Alternatives As an alternative solution, we could change crates that depend on `tracing-subscriber` with `default-features = false` to also explicitly ensure that the `std` feature is enabled (which might be worth doing regardless). This is what PR #1659 does. However, I think the approach in this branch is more correct; the feature flags that require standard library support should automatically enable it. This provides a better experience for most users, who are simply adding `default-features = false` in order to avoid enabling un-needed features, not to support `no_std`, and would like enabling a feature flag to *actually* enable that feature. `no_std` users will know not to enable `registry`, `fmt`, and `env-filter` because the documentation notes that those features require the standard library.
Motivation
Currently, some
tracing-subscriber
dependencies in other crates usedefault-features = false
, to ensure that unneeded default features oftracing-subscriber
are not inadvertently enabled. However, some of thefeatures those crates enable also require the
std
feature flag. Thedefault-features = false
config disables thestd
feature, so therequired features are not available.
Solution
This branch changes those crates' dependencies on
tracing-subscriber
to also enable the
std
feature.Alternatives
As an alternative solution, we could change
tracing-subscriber
'sfeature flags so that features that require the standard library also
enable the
std
feature, rather than having those features requireit. I think this might actually provide a better experience for most
users.