Skip to content
This repository has been archived by the owner on Sep 13, 2023. It is now read-only.

fix #43: pub use crates, add set_log_verbosity and feature=full-throttle #51

Closed
wants to merge 4 commits into from

Conversation

vitiral
Copy link
Contributor

@vitiral vitiral commented Feb 10, 2018

This does several things to, some of which is to integrate better with the ergo ecosystem.

  • Adds feature=full-throttle as suggested in Integrate with the ergo ecosystem #43, which allows disabling some of the included crates
  • Moves set_log_verbosity into a function so that users can more cleanly migrate away from the main! macro (I already had need of this in artifact).
  • Publically uses crates to improve the import story. For instance, to use clap (which is exported by quicli), I had to do: use quicli::prelude::structopt::clap, which now I can do use quicli::structopt::clap.

I am currently using both ergo and quicli together to rewrite artifact's CLI. I'll keep opening bugs/PRs as I find them!

@vitiral
Copy link
Contributor Author

vitiral commented Feb 10, 2018

just a sec, something isn't right -- I can't use derive(StructOpt) anymore...

@vitiral
Copy link
Contributor Author

vitiral commented Feb 10, 2018

nevermind, all is well again (I knew there was a merge conflict! Thanks for adding that test)

Copy link
Owner

@killercup killercup left a 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
Copy link
Owner

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 }

Copy link
Contributor Author

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 😄

Copy link
Owner

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

Copy link
Contributor Author

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?!?!

Copy link
Owner

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!

Copy link
Contributor Author

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<()> {
Copy link
Owner

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)

Copy link
Contributor Author

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!

Copy link
Owner

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.

Copy link
Contributor Author

@vitiral vitiral Feb 10, 2018

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;
Copy link
Owner

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.

Copy link
Contributor Author

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.

@vitiral
Copy link
Contributor Author

vitiral commented Feb 10, 2018

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.

I don't think I agree. clap is exported from structopt for a reason -- structopt is just a wrapper. quicli (and ergo) are just "ecosystem conglomeration and wrapping crates". It is true that we try to provide a clean "interface", but sometimes you need the "wrapped type". It's a maintenance burden to require the user to specify the version of clap they want when all they really want is "the same version as structopt uses".

I'd definetly be interested in more thoughts/opinions as ergo is taking the position of always using pub extern crate to uphold this contract.

@vitiral
Copy link
Contributor Author

vitiral commented Feb 10, 2018

I opened #52 for the pub extern crate issue. I'll remove those changes as well.

@vitiral
Copy link
Contributor Author

vitiral commented Feb 10, 2018

Okay, I think the only outstanding issue is the exported log function.

@killercup
Copy link
Owner

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.

@vitiral
Copy link
Contributor Author

vitiral commented Feb 11, 2018

So I'm thinking the most flexibility could be gained by an API like:

fn set_log_verbosity(lowest: u64, levels: &[(&str, u64)])
  • lowest is the lowest log level, i.e. set to 1 to enable all warnings.
  • levels is a tuple containing the custom levels for specific crates.

This gives complete flexibility but is also very simple.

@vitiral
Copy link
Contributor Author

vitiral commented Feb 12, 2018

@killercup what do you think about the new API?

@vitiral
Copy link
Contributor Author

vitiral commented Feb 13, 2018

I'm going to make the logging stuff a separate issue.

Edit: #56

@vitiral
Copy link
Contributor Author

vitiral commented Feb 13, 2018

Okay, I made set_log_verbosity hidden so it is now just an implementation detail of the current main! macro. Hopefully that works for you!

@killercup
Copy link
Owner

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.

@killercup
Copy link
Owner

Gotta be honest, though, a PR that just adds the feature flag would've been merged for a while now ;)

@vitiral
Copy link
Contributor Author

vitiral commented Feb 16, 2018 via email

@vitiral vitiral closed this Mar 12, 2018
@vitiral
Copy link
Contributor Author

vitiral commented Mar 12, 2018

going to reopen this as a separate PR for just the feature flag.

@vitiral vitiral mentioned this pull request Mar 12, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants