-
Notifications
You must be signed in to change notification settings - Fork 31
fix #43: pub use crates, add set_log_verbosity and feature=full-throttle #51
Conversation
just a sec, something isn't right -- I can't use |
nevermind, all is well again (I knew there was a merge conflict! Thanks for adding that test) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am currently using both ergo and quicli together to rewrite artifact's CLI. I'll keep opening bugs/PRs as I find them!
Cool!
Publically uses crates to improve the import story.
Not sure this is a good idea. If you are honestly using clap
in your crate for anything, you should probably add it to your Cargo.toml
and use the same version as quicli. That's more obvious to any contributors including your future self. I'd be interested in what other think about this.
Cargo.toml
Outdated
|
||
[dependencies.serde] | ||
version = "1.0.27" | ||
optional = true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you convert all these to inline-table style ? Like this: serde = { version = "1", optional = true }
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sure, but anytime you do a cargo add
they will be converted back 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
have you heard the good news of cargo install cargo-edit --vers 0.3.0-beta.1 -f
? :D
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what? No! Does it preserve formatting?!?!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It should! Please tell me if it breaks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
praise the rust godess, it works!
src/easy_log.rs
Outdated
/// This is used in the [`main!`] macro. You should typically use that instead. | ||
/// | ||
/// [`main!`]: macro.main.html | ||
pub fn set_log_verbosity(verbosity: u64) -> prelude::Result<()> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we do expose this, we should probably also make it parametrized over package_name
(currently Some(env!("CARGO_PKG_NAME"))
) and default_level
. I have more thoughts on this but wrote them in #46 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like that.
I'm not sure what default_level
is. Is that an argument? How would it be used? I currently like the behavior that verbosity=0
gives you the default of error logging. If you don't want any logging than just don't call set_log_verbosity
!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, I retract that comment. Let's either
- change this to a thing that does the mapping from int to log level (basically return
log_level
and skip the rest) - or to a more complicated thing with a builder like
Logger::new().this_crate(2).other_crates("Warn").init()?
(note it's generic over ints and strings) and go all in, with the option of adding more cool stuff later on (e.g. detect that this is run without a tty and write to syslog/journald)
The former is a bit conservative and requires you to write the LoggerBuilder call with the two filters yourself. It also gives you more flexibility that way, of course. The latter is way more complicated, but might allow using quicli in more contexts.
FYI, I haven't seen an easy logging library yet that gives us more than env_logger. Most others require setting up a bunch of different adaptors.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I actually think env_logger
is the right choice for this library. I didn't realize it lets you control the logging through both a specified verbosity and env-vars.
Hmm... I think that is providing too much complexity. What if there was a other_verbosity: Option<u64>
which by default would do the behavior you defined in #46, but would allow you to do something like other_verbosity: Some(u64::min(cmd.verbosity, 2))
.
I think kicking off the logging is a huge benefit here. I don't think quicli
is the right place to solve all logging ergonomics.
src/lib.rs
Outdated
extern crate serde; | ||
#[cfg(feature="full-throttle")] | ||
#[macro_use] | ||
pub extern crate serde_derive; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I agree with making these dependencies public. Let me think about this for a bit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Definitely. I think I'll remove it from this review and open an issue for discussion.
I don't think I agree. I'd definetly be interested in more thoughts/opinions as |
I opened #52 for the |
Okay, I think the only outstanding issue is the exported log function. |
Thanks for the quick changes! I'll release 0.2 with structopt 0.2 in a bit, this will make it into 0.2.1. |
So I'm thinking the most flexibility could be gained by an API like:
This gives complete flexibility but is also very simple. |
@killercup what do you think about the new API? |
I'm going to make the logging stuff a separate issue. Edit: #56 |
Okay, I made |
Thanks for the updates, @vitiral! And sorry for taking to long to get back to you. I'm currently dealing with some other things, but hope to get around to reviewing this over the weekend. |
Gotta be honest, though, a PR that just adds the feature flag would've been merged for a while now ;) |
Ya, keep changes small :)
Most of this was an experiment to show what was needed to integrate with
ergo. I'm happy to take a bit longer to figure that out. I think the issues
opened for further discussion were worth the friction, and this showed to
me that we should be able to integrate cleanly eventually.
|
going to reopen this as a separate PR for just the feature flag. |
This does several things to, some of which is to integrate better with the
ergo
ecosystem.feature=full-throttle
as suggested in Integrate with the ergo ecosystem #43, which allows disabling some of the included cratesset_log_verbosity
into a function so that users can more cleanly migrate away from themain!
macro (I already had need of this inartifact
).clap
(which is exported byquicli
), I had to do:use quicli::prelude::structopt::clap
, which now I can douse quicli::structopt::clap
.I am currently using both
ergo
andquicli
together to rewriteartifact
's CLI. I'll keep opening bugs/PRs as I find them!