-
Notifications
You must be signed in to change notification settings - Fork 723
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
tracing-subscriber
should not use nu-ansi-term
and prefer another crate like owo_colors
or colored
#2759
Comments
Since the dependency on |
I took a stab at using owo-colors, but it seems like it's not quite as straightforward jam1garner/owo-colors#123 I believe the same issue would also apply to most other coloring crates. I wonder what the correct fix would be. |
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. |
@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 🥲 tracing/tracing-subscriber/Cargo.toml Line 23 in 908cc43
Definitely a lovely crate that I might remember for other projects. |
anstream's MSRV has been lowered to 1.65.0. That's still higher than tracing-subscriber's MSRV though. |
Feature Request
tracing-subscriber
should use another coloring crate, rather thannu-ansi-term
(for example:termcolor
,owo-colors
, or colored)Crates
tracing-subscriber
Motivation
Because:
tracing-subscriber
, being part oftracing
, and ultimately thetokio
project, is influential on those who do not know the details of Rust's crate ecosystem, and might think thatnu-ansi-term
is a good choice for styling terminal outputnu-ansi-term
is used mostly because it provides continuity fromansi-term
nu-ansi-term
, inherited fromansi_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 tonu-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 bothio::Write
andfmt::Write
, as we are only interested in printing out string/formattable/utf-8 data; compare instead withowo_color
's approach, where formatters (which can write to any stream willing to present itself as anfmt::Write
implementor)nu-ansi-term
; due to their design principlesnu-ansi-term
wants to avoid using macros, which also makes it more difficult to extendnu-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, andwrite_str
would suffice --- I think the reason whywrite!
is used is because when trying to use thewrite_str
method thatAnyWrite
provides in that context, one runs into issues specifying whichwrite_str
to call:io::Write
r's impl ofAnyWrite
(which uses itswrite_all
under the hood), orfmt::Write
r's (which uses itswrite_str
under the hood)?Proposal
tracing-subscriber
should use another coloring crate, rather thannu-ansi-term
(for example:termcolor
,owo-colors
, or colored)See here for more discussion on the technical pros/cons of each choice: nicoburns/blessed-rs#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, thenu-ansi-team
has concerns of its own around such upgrades, such as requiring backwards compatibility.The text was updated successfully, but these errors were encountered: