-
Notifications
You must be signed in to change notification settings - Fork 24
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
Direct access to the i8 value of verbosity #53
Comments
I see that supporting tracing is an aim for you. Did you see the example? https://github.com/clap-rs/clap-verbosity-flag/blob/master/examples/example_tracing.rs I kind of want this feature but only because I want to compare on the if level < warn {
// suppress a bit more
}
if level < error {
// suppress a bit more
} |
Is |
Well, this is working so I don’t know what I did. I think I got confused between if opt.verbose.log_level_filter() <= LevelFilter::Warn {
eprintln!("Hide command's stdout");
}
if opt.verbose.log_level_filter() <= LevelFilter::Error {
eprintln!("Hide command's stderr");
} Sorry for the noise, and thank you for the pointer. |
Is the original issue (from @khultman) resolved then? |
Thanks, I did see this. I'm giving using tracing as an example, but my thought here is that direct access to the |
The current definition of fn verbosity(&self) -> i8 {
level_value(L::default()) - (self.quiet as i8) + (self.verbose as i8)
} I feel that the One way around this problem is if we have a function that returns the net result of the verbosity flags. The difference is in the name / documentation and in not including I am somewhat hesitant to include such a function as the use case is a bit off the beaten path, relying on custom log levels decoupled from |
I agree.
After re-visiting this I agree and would opt for not include such a function. |
A use case for this is enabling cli apps to use the verbosity flags to have control over how e.g. color_eyre displays backtrace / spantraces. This is pretty similar to the replacing the I suppose that could be implemented as: match cli.verbose.log_level() {
Level::Warn => env::set_var("RUST_BACKTRACE", "1"),
Level::Error => env::set_var("RUST_BACKTRACE", "full"),
_ => {}
} |
imo |
Having direct access to Is that something you think it's possible to achieve without having those variables as public? |
At least in cargo's case, Are you wanting your env variables to be bools or to be numeric levels? And are you trying to add them to the CLI, rather than the CLI shadowing? |
Unsure why the default api to make this value private, but making the value public allows more flexible use of this library. PR submitted for this change.
The text was updated successfully, but these errors were encountered: