This is a discussion on what the use case and requirements of these two libraries are.

stdcli's goal is basically to make creating a CLI in rust more like creating one in python from a user experience and ergonomics point of view. This means:

• batteries included
• almost everything you need is already imported
  • python, because of it's duct typing and general unsafetly, does not require you to import "something" to use methods on its types. Rust, on the other hand requires you to import a boatload of traits.
  • related: #18
• "flush out" macros that should be in the stdlib like hashmap!
• (not yet in stdcli but planned) provide feature flags to control which libraries you want so you can develop with "full batteries" and then pare everything down as your application dependencies become more clear. For instance, maybe ansi_term, pretty_tables, termstyle and tabwriter are all in the "full batteries" package, but then you can do features = ["style_termstyle"] to only have termstyle

Also related: require that all versions in quicli are of the form >=VERSION so that the user can mostly control which version is used.

What is quicli?

Qui CLI seems to have similar but not completely overlapping goals. I would prefer we merge forces rather than create competing libraries.

I think it should be possible through liberal use of feature flags to accomplish any usecase a user might want. I.e. features = "full_batteries" would depend-on-the-world, but features = "light" would give very minimal dependencies, and everything in between.

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

• Adds feature=full-throttle as suggested in #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!

I am the creator and maintainer of the new path_abs crate and I think it solves a lot of ergonomic problems in rust (problems I see you re-solving with the fs module!).

Questions:

• should we export path_abs types?
• should fs module be deprecated?

Thanks!

I want to add some more examples and show them in a nice way, but I'm not yet sure how best to do that.

One idea:

• Add docs/ folder that is deploy via Github Pages (with Jekyll)
• put "literate Rust" in there (Markdown with code blocks)
• parse the Markdown files in there with waltz and test that code as subcrate(s) on CI

(in the most annoying way)

This is useful for when you want to do more complicated manual defaults for arguments, such as trying to read from an environment variable if an argument is not provided.

It doesn't look like I can get it to re-export the proc macro like I can for the proc-macro _derive crate.

Since we already tell people to add structopt to their Cargo.toml, it's might not look like a big step to make them add #[macro_use] extern crate structopt; to their files, too. But still, this sadly is worse than what we have right now.

cf. https://github.com/TeXitoi/structopt/pull/50#issuecomment-363039922

cc @TeXitoi

Is this (more) readable? Can people new to Rust easily understand this code? Do they feel like they can write this themselves?

main!(|args: Cli, log_level: verbosity| {
    read_file(&args.file)?
        .lines()
        .take(args.count)
        .for_each(|line| println!("{}", line));
});

Also adds testing on CI. Rending this in some way other than on github.com will come at a later point.

TODO

Required to land this

• [x] Set up waltz on Travis
• [x] Move over Readme guide
• [x] Move over commit guide

Stretch goals

• [ ] Cache target dir between crates generated waltz
• [x] Set up github pages rendering with simple template
• [ ] Move over image resize guide from #23

cc #16

Before anything else, thanks for this very neat crate! With the logging, failure and struct-opt ready for use, it makes it really fast to start building quick and clean scripts. So thanks :)

This PR aims at implementing #85

Hi,

I wrote a simple toy example today but it seems by StructOpt declaration might be invalid - I have a few errors:

error[E0425]: cannot find value `to` in this scope
  --> src\main.rs:24:17
   |
24 | #[derive(Debug, StructOpt)]
   |                 ^^^^^^^^^
   |                 |
   |                 `self` value is only available in methods with `self` parameter
   |                 help: try: `self.to`

error[E0425]: cannot find value `w` in this scope
  --> src\main.rs:24:17
   |
24 | #[derive(Debug, StructOpt)]
   |                 ^^^^^^^^^ not found in this scope

error[E0425]: cannot find value `from` in this scope
  --> src\main.rs:24:17
   |
24 | #[derive(Debug, StructOpt)]
   |                 ^^^^^^^^^
   |                 |
   |                 `self` value is only available in methods with `self` parameter
   |                 help: try: `self.from`

error[E0425]: cannot find value `r` in this scope
  --> src\main.rs:24:17
   |
24 | #[derive(Debug, StructOpt)]
   |                 ^^^^^^^^^ not found in this scope

error[E0425]: cannot find value `Fahrenheit` in this scope
  --> src\main.rs:24:17
   |
24 | #[derive(Debug, StructOpt)]
   |                 ^^^^^^^^^ not found in this scope
help: possible candidate is found in another module, you can import it into scope
   |
7  | use TemperatureUnit::Fahrenheit;

Here's the source code - https://gist.github.com/blakehawkins/5f848d3a4eff2f0a67282cc1cb730022

Any advice appreciated! May be a regression?

Hey @killercup, you've probably been waiting for this feature request 😄

I am nearing completion of the initial release of ergo. There is a LOT of overlap between these two crates but there is also several areas that there is not overlap.

My suggestion is to have a minimal feature set which only

• exports the main! macro
• exports log and envlog crates and types
• exports structopt macro and types
• exports failure macros and types

This would allow quicli to fit cleanly within the ergo crate ecosystem, as I have no desire for ergo to perform these operations. Theoretically I could create an ergo-cli crate which is pretty much a fork of quicli with these features -- but I don't want to do that!

Another advantage of this is that it could be part of the "story" of developing an application:

• when you start out, use just quicli
• when you need a larger stdlib, set features=minimal and import ergo
• keep rusting!

I think this is caused by https://github.com/rust-lang-nursery/failure/issues/258 and https://github.com/rust-lang-nursery/failure/issues/110, but I thought it worth mentioning, as I hit this upgrading from quicli 0.3 to 0.4.

I'm not sure there's anything that can be done in this crate though, so feel free to close if you want.

Reproduction:

Source

use quicli::prelude::*;

fn main() -> CliResult {
    bail!("This does not work!");
}

Reproduction

cargo new quicli_bail; cd quicli_bail
cargo install cargo-edit
cargo add quicli
echo -e 'use quicli::prelude::*;\n\nfn main() -> CliResult {\n    bail!("This does not work!");\n}' >src/main.rs
cargo build

Result:

   Compiling test_quicli v0.1.0 (/Users/gib/tmp/test_quicli)
error[E0308]: mismatched types
 --> src/main.rs:4:5
  |
4 |     bail!("This doesn't work!");
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected struct `exitfailure::ExitFailure`, found struct `failure::error::Error`
  |
  = note: expected type `exitfailure::ExitFailure`
             found type `failure::error::Error`
  = note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)

error: aborting due to previous error

For more information about this error, try `rustc --explain E0308`.
error: Could not compile `test_quicli`.

To learn more, run the command again with --verbose.

After I finished the thumbnail tutorial, I tried to test it and got this error

Error: No files match pattern `rust_memes/*`

After seeing that, I progressively commented out more code to get a minimal reproduction, and I was able to find that this block of code doesn't match anything

use quicli::prelude::*;

fn main() -> CliResult {
    let files = glob("src/*")?;
    println!("{:?}", files);
    Ok(())
}

~/dev/rust/thumbify master
❯ cargo run --
   Compiling thumbify v0.1.0 (/home/chris.pickard/dev/rust/thumbify)
    Finished dev [unoptimized + debuginfo] target(s) in 1.11s
     Running `target/debug/thumbify`
Error: No files match pattern `src/*`

Even though I clearly have matching files in my src/ directory

~/dev/rust/thumbify master
❯ ls src
main.rs

I'm sorry, I feel like I'm quite a thorn in your side at the moment

As it is right now, the -vvv enables logging only for the main crate. For some use-cases, the ability to log everything would make more sense. Any way to achieve it?

Right now even RUST_LOG no longer works.

I love quicli, here is a suggestion on how to improve it (in the form of a PR).

Since we control the main method, there is no way that the logging init can fail. Given this, we can use the logging functionality for outputting any errors that are returned from the main method. This is what I have implemented in this PR.

Apart from this, there are a few small improvements, for example removing a warning in an edge case where all paths lead to an error, and adding tests for the different forms of the main! macro.

Let me know what you think!

Would it make sense for human-panic to be part of quicli? I feel it'd make a lot of sense for it to be part of almost every CLI application, but I'm not sure if it exceeds quicli's scope.

I think it might be an interesting addition to consider. Keen to hear thoughts on this!

Refs

• https://github.com/yoshuawuyts/human-panic