subscriber: add ability to disable ANSI without crate feature #2532

daxpedda · 2023-03-26T18:28:48Z

Motivation

Currently it is not possible to disable ANSI in fmt::Subscriber without enabling the ansi crate feature. This makes it difficult for users to implement interoperable settings that are controllable with crate features without having to pull in the dependencies ansi does.

I hit this while writing an application with multiple logging options set during compile-time and I wanted to cut down on dependencies if possible.

Solution

This adds a simple fmt::Subscriber::disable_ansi() that is available even without the ansi crate feature.

hawkw

Hmm, I'm not sure if I like having an API with two separate ways to disable ANSI colors (with_ansi(false) and disable_ansi()), that seems a bit confusing for users. As an alternative solution, what do you think about changing with_ansi to no longer require the "ansi" feature flag, and having it print a warning (and possibly a debug_assert!) if the argument is true and the "ansi" feature flag is disabled?

daxpedda · 2023-04-14T10:24:25Z

Hmm, I'm not sure if I like having an API with two separate ways to disable ANSI colors (with_ansi(false) and disable_ansi()), that seems a bit confusing for users.

I took this idea from reqwest btw: https://docs.rs/reqwest/0.11.16/reqwest/struct.ClientBuilder.html#method.no_brotli.

As an alternative solution, what do you think about changing with_ansi to no longer require the "ansi" feature flag, and havin

Sounds good to me!

daxpedda · 2023-04-14T10:30:06Z

As an alternative solution, what do you think about changing with_ansi to no longer require the "ansi" feature flag, and having it print a warning (and possibly a debug_assert!) if the argument is true and the "ansi" feature flag is disabled?

Was just about to implement this when I realized I'm not sure how to "print" a warning here. Tracing isn't set up at this point yet, so should I be using eprintln!() then?

hawkw · 2023-04-14T16:11:04Z

As an alternative solution, what do you think about changing with_ansi to no longer require the "ansi" feature flag, and having it print a warning (and possibly a debug_assert!) if the argument is true and the "ansi" feature flag is disabled?

Was just about to implement this when I realized I'm not sure how to "print" a warning here. Tracing isn't set up at this point yet, so should I be using eprintln!() then?

eprintln! is fine here.

Currently it is not possible to disable ANSI in `fmt::Subscriber` without enabling the `ansi` crate feature. This makes it difficult for users to implement interoperable settings that are controllable with crate features without having to pull in the dependencies `ansi` does. This removes the crate feature requirement on `fmt::Subscriber::with_ansi()`, but will print a warning if trying to enable ANSI terminal colors without the crate feature.

daxpedda · 2023-04-14T16:34:47Z

tracing-subscriber/src/fmt/fmt_subscriber.rs

+        #[cfg(not(feature = "ansi"))]
+        if ansi {
+            const ERROR: &str =
+                "tracing-subscriber: enabled ANSI terminal colors without the `ansi` crate feature";
+            #[cfg(debug_assertions)]
+            panic!("{}", ERROR);
+            #[cfg(not(debug_assertions))]
+            eprintln!("{}", ERROR);
+        }


I hope this is appropriate.
Should I add some documentation on with_ansi() about the warning? I didn't feel it's needed really.

I think we should document that enabling ANSI formatting requires the feature flag. Now that the method itself is no longer feature gated, there's no obvious way to determine from the documentation that the feature flag is necessary.

hawkw

Overall, this looks great! I had some suggestions for rewording the documentation and the error message --- let me know what you think?

hawkw · 2023-04-14T18:07:26Z

tracing-subscriber/src/fmt/fmt_subscriber.rs

+        #[cfg(not(feature = "ansi"))]
+        if ansi {
+            const ERROR: &str =
+                "tracing-subscriber: enabled ANSI terminal colors without the `ansi` crate feature";


This error message describes what happened, rather than why it happened, which might be more helpful for the user. How about rephrasing it as something like this:

Suggested change

"tracing-subscriber: enabled ANSI terminal colors without the `ansi` crate feature";

"tracing-subscriber: the 'ansi' crate feature is required to enable ANSI terminal colors";

That's way better indeed.

I found that in other parts of the documentation in tracing are using ` instead of ' with crate features, so I used it here too. WDYT?

hawkw · 2023-04-14T18:13:27Z

tracing-subscriber/src/fmt/fmt_subscriber.rs

+        #[cfg(not(feature = "ansi"))]
+        if ansi {
+            const ERROR: &str =
+                "tracing-subscriber: enabled ANSI terminal colors without the `ansi` crate feature";
+            #[cfg(debug_assertions)]
+            panic!("{}", ERROR);
+            #[cfg(not(debug_assertions))]
+            eprintln!("{}", ERROR);
+        }


I think we should document that enabling ANSI formatting requires the feature flag. Now that the method itself is no longer feature gated, there's no obvious way to determine from the documentation that the feature flag is necessary.

tracing-subscriber/src/fmt/fmt_subscriber.rs

tracing-subscriber/src/fmt/mod.rs

Co-Authored-By: Eliza Weisman <eliza@buoyant.io>

hawkw

looks great to me!

## Motivation Currently it is not possible to disable ANSI in `fmt::Subscriber` without enabling the "ansi" crate feature. This makes it difficult for users to implement interoperable settings that are controllable with crate features without having to pull in the dependencies "ansi" does. I hit this while writing an application with multiple logging options set during compile-time and I wanted to cut down on dependencies if possible. ## Solution This changes `fmt::Subscriber::with_ansi()` to not require the "ansi" feature flag. This way, `with_ansi(false)` can be called even when the "ansi" feature is disabled. Calling `with_ansi(true)` when the "ansi" feature is not enabled will panic in debug mode, or print a warning if debug assertions are disabled. Co-authored-by: Eliza Weisman <eliza@buoyant.io>

@keepsimple1

# 0.3.17 (April 21, 2023) This release of `tracing-subscriber` fixes a build error when using `env-filter` with recent versions of the `regex` crate. It also introduces several minor API improvements. ### Fixed - **env-filter**: Add "unicode-case" and "unicode-perl" to the `regex` dependency, fixing a build error with recent versions of `regex` (#2566) - A number of minor documentation typos and other fixes (#2384, #2378, #2368, #2548) ### Added - **filter**: Add `fmt::Display` impl for `filter::Targets` (#2343) - **fmt**: Made `with_ansi(false)` no longer require the "ansi" feature, so that ANSI formatting escapes can be disabled without requiring ANSI-specific dependencies (#2532) ### Changed - **fmt**: Dim targets in the `Compact` formatter, matching the default formatter (#2409) Thanks to @keepsimple1, @andrewhalle, @LeoniePhiline, @LukeMathWalker, @howardjohn, @daxpedda, and @dbidwell94 for contributing to this release!

@keepsimple1

This release of `tracing-subscriber` fixes a build error when using `env-filter` with recent versions of the `regex` crate. It also introduces several minor API improvements. - **env-filter**: Add "unicode-case" and "unicode-perl" to the `regex` dependency, fixing a build error with recent versions of `regex` (tokio-rs#2566) - A number of minor documentation typos and other fixes (tokio-rs#2384, tokio-rs#2378, tokio-rs#2368, tokio-rs#2548) - **filter**: Add `fmt::Display` impl for `filter::Targets` (tokio-rs#2343) - **fmt**: Made `with_ansi(false)` no longer require the "ansi" feature, so that ANSI formatting escapes can be disabled without requiring ANSI-specific dependencies (tokio-rs#2532) - **fmt**: Dim targets in the `Compact` formatter, matching the default formatter (tokio-rs#2409) Thanks to @keepsimple1, @andrewhalle, @LeoniePhiline, @LukeMathWalker, @howardjohn, @daxpedda, and @dbidwell94 for contributing to this release!

…rs#2532) ## Motivation Currently it is not possible to disable ANSI in `fmt::Subscriber` without enabling the "ansi" crate feature. This makes it difficult for users to implement interoperable settings that are controllable with crate features without having to pull in the dependencies "ansi" does. I hit this while writing an application with multiple logging options set during compile-time and I wanted to cut down on dependencies if possible. ## Solution This changes `fmt::Subscriber::with_ansi()` to not require the "ansi" feature flag. This way, `with_ansi(false)` can be called even when the "ansi" feature is disabled. Calling `with_ansi(true)` when the "ansi" feature is not enabled will panic in debug mode, or print a warning if debug assertions are disabled. Co-authored-by: Eliza Weisman <eliza@buoyant.io>

@keepsimple1

# 0.3.17 (April 21, 2023) This release of `tracing-subscriber` fixes a build error when using `env-filter` with recent versions of the `regex` crate. It also introduces several minor API improvements. ### Fixed - **env-filter**: Add "unicode-case" and "unicode-perl" to the `regex` dependency, fixing a build error with recent versions of `regex` (tokio-rs#2566) - A number of minor documentation typos and other fixes (tokio-rs#2384, tokio-rs#2378, tokio-rs#2368, tokio-rs#2548) ### Added - **filter**: Add `fmt::Display` impl for `filter::Targets` (tokio-rs#2343) - **fmt**: Made `with_ansi(false)` no longer require the "ansi" feature, so that ANSI formatting escapes can be disabled without requiring ANSI-specific dependencies (tokio-rs#2532) ### Changed - **fmt**: Dim targets in the `Compact` formatter, matching the default formatter (tokio-rs#2409) Thanks to @keepsimple1, @andrewhalle, @LeoniePhiline, @LukeMathWalker, @howardjohn, @daxpedda, and @dbidwell94 for contributing to this release!

daxpedda requested review from hawkw, davidbarsky and a team as code owners March 26, 2023 18:28

hawkw reviewed Apr 13, 2023

View reviewed changes

daxpedda force-pushed the disable-ansi branch from eb0990b to 223e47d Compare April 14, 2023 10:30

daxpedda force-pushed the disable-ansi branch from 223e47d to 2ebcd2b Compare April 14, 2023 16:34

daxpedda commented Apr 14, 2023

View reviewed changes

daxpedda requested a review from hawkw April 14, 2023 16:35

hawkw requested changes Apr 14, 2023

View reviewed changes

Address review

f035446

Co-Authored-By: Eliza Weisman <eliza@buoyant.io>

daxpedda force-pushed the disable-ansi branch from f68fb64 to f035446 Compare April 14, 2023 18:29

hawkw approved these changes Apr 14, 2023

View reviewed changes

hawkw enabled auto-merge (squash) April 14, 2023 19:29

hawkw merged commit 1cb523b into tokio-rs:master Apr 14, 2023
55 checks passed

hawkw mentioned this pull request Apr 21, 2023

backport a gigantic pile of stuff #2570

Merged

hawkw mentioned this pull request Apr 22, 2023

subscriber: prepare to release v0.3.17 #2571

Merged

davidbarsky mentioned this pull request Sep 26, 2023

chore: backport roughly a year's worth of changes #2728

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

subscriber: add ability to disable ANSI without crate feature #2532

subscriber: add ability to disable ANSI without crate feature #2532

daxpedda commented Mar 26, 2023

hawkw left a comment

daxpedda commented Apr 14, 2023

daxpedda commented Apr 14, 2023

hawkw commented Apr 14, 2023

daxpedda Apr 14, 2023

hawkw Apr 14, 2023

hawkw left a comment

hawkw Apr 14, 2023

daxpedda Apr 14, 2023 •

edited

hawkw Apr 14, 2023

hawkw left a comment

	"tracing-subscriber: enabled ANSI terminal colors without the `ansi` crate feature";
	"tracing-subscriber: the 'ansi' crate feature is required to enable ANSI terminal colors";

subscriber: add ability to disable ANSI without crate feature #2532

subscriber: add ability to disable ANSI without crate feature #2532

Conversation

daxpedda commented Mar 26, 2023

Motivation

Solution

hawkw left a comment

Choose a reason for hiding this comment

daxpedda commented Apr 14, 2023

daxpedda commented Apr 14, 2023

hawkw commented Apr 14, 2023

daxpedda Apr 14, 2023

Choose a reason for hiding this comment

hawkw Apr 14, 2023

Choose a reason for hiding this comment

hawkw left a comment

Choose a reason for hiding this comment

hawkw Apr 14, 2023

Choose a reason for hiding this comment

daxpedda Apr 14, 2023 • edited

Choose a reason for hiding this comment

hawkw Apr 14, 2023

Choose a reason for hiding this comment

hawkw left a comment

Choose a reason for hiding this comment

daxpedda Apr 14, 2023 •

edited