`tracing-subscriber` should not use `nu-ansi-term` and prefer another crate like `owo_colors` or `colored`

[bzm3r]

Feature Request

tracing-subscriber should use another coloring crate, rather than nu-ansi-term (for example: termcolor, owo-colors, or colored)

Crates

tracing-subscriber

Motivation

Because:

• tracing-subscriber, being part of tracing, and ultimately the tokio project, is influential on those who do not know the details of Rust's crate ecosystem, and might think that nu-ansi-term is a good choice for styling terminal output
• it seems nu-ansi-term is used mostly because it provides continuity from ansi-term
• nu-ansi-term, inherited from ansi_term before it, has questionable design decisions which do not make it easy to write ANSI output to terminal with zero additional allocation (for example, format_args! cannot be styled, and adding that functionality to nu-ansi-term is not easy, for a few different reasons, but here are a couple that stick out to me:
  • AnyWrite seems to be a design error because it is not necessary to be generic over both io::Write and fmt::Write, as we are only interested in printing out string/formattable/utf-8 data; compare instead with owo_color's approach, where formatters (which can write to any stream willing to present itself as an fmt::Write implementor)
  • there is a lot of unnecessary, code duplication, making it more error prone to develop for nu-ansi-term; due to their design principles nu-ansi-term wants to avoid using macros, which also makes it more difficult to extend
• other performance reasons: apart from nu-ansi-term not making it easy to write ANSI styled output with zero-allocation, write! is often used where it doesn't need to be, and write_str would suffice --- I think the reason why write! is used is because when trying to use the write_str method that AnyWrite provides in that context, one runs into issues specifying which write_str to call: io::Writer's impl of AnyWrite (which uses its write_all under the hood), or fmt::Writer's (which uses its write_str under the hood)?

Proposal

tracing-subscriber should use another coloring crate, rather than nu-ansi-term (for example: termcolor, owo-colors, or colored)

See here for more discussion on the technical pros/cons of each choice: https://github.com/nicoburns/blessed-rs/issues/100

Alternatives

The primary alternative is to make upstream changes to nu-ansi-term. It requires spending a lot of time to re-produce work that others have done, even better. Furthermore, the nu-ansi-team has concerns of its own around such upgrades, such as requiring backwards compatibility.

[hawkw]

Since the dependency on nu-ansi-term is not exposed in public APIs, I would happily accept a PR that replaces it with a different crate, provided that the replacement also supports tracing-subscriber's minimum supported Rust version.

[stefnotch]

I took a stab at using owo-colors, but it seems like it's not quite as straightforward https://github.com/jam1garner/owo-colors/issues/123

I believe the same issue would also apply to most other coloring crates. I wonder what the correct fix would be.

[djc]

Maybe have a look at anstream (which is used by clap)?

https://docs.rs/anstream/latest/anstream/

IIRC it has a fairly aggressive MSRV policy which might not be a great fit.

[stefnotch]

@djc Thank you!

I looked into it just now, it's a lovely crate (more specifically, anstyle). It also doesn't seem to have that issue, since it's a more low level crate for working with terminal colors.

And it sadly isn't immediately usable, since it's MSRV is 1.70.0 🥲 https://github.com/rust-cli/anstyle/blob/476efbc8c68ae473eb17ea53385527a916226bbf/Cargo.toml#L8 while tracing-subscriber's MSRV is 1.63.0 https://github.com/tokio-rs/tracing/blob/908cc432a5994f6e17c8f36e13c217dc40085704/tracing-subscriber/Cargo.toml#L23

Definitely a lovely crate that I might remember for other projects.

[stefnotch]

anstream's MSRV has been lowered to 1.65.0. That's still higher than tracing-subscriber's MSRV though. https://github.com/rust-cli/anstyle/blob/76f6849f826b3f73e827890e9abab5113820ffec/Cargo.toml#L8