1cdb2250e8
Before: - `bool`: a flag - `Option<_>`: not required - `Option<Option<_>>` is not required and when it is present, the value is not required - `Vec<_>`: multiple values, optional - `Option<Vec<_>>`: multiple values, min values of 0, optional After: - `bool`: a flag - `Option<_>`: not required - `Option<Option<_>>` is not required and when it is present, the value is not required - `Vec<_>`: multiple occurrences, optional - optional: `Vec` implies 0 or more, so should not imply required - `Option<Vec<_>>`: multiple occurrences, optional - optional: Use over `Vec` to detect when no option being present when using multiple values Motivations: My priorities were: 1. Are we getting in the users way? 2. Does the API make sense? 3. Does the API encourage best practices? I was originally concerned about the lack of composability with `Option<Option<_>>` and `Option<Vec<_>>` (and eventually `Vec<Vec<_>>`). It prescribes special meaning to each type depending on where it shows up, rather than providing a single meaning for a type generally. You then can't do things like have `Option<_>` mean "required argument with optional value" without hand constructing it. However, in practice the outer type correlates with the argument occurrence and the inner type with the value. It is rare to want the value behavior without also the occurrence behavior. So I figure it is probably fine as long as people can set the flags to manually get the behavior they want. `Vec<_>` implies multiple occurrences, rather than multiple values. Anecdotally, whenever I've used the old `Arg::multiple`, I thought I was getting `Arg::multiple_occurrences` only. `Arg::multiple_values`, without any bounds or delimiter requirement, can lead to a confusing user experience and isn't a good default for these. On top of that, if someone does have an unbounded or a delimiter multiple values, they are probably also using multiple occurrences. `Vec<_>` is optional because a `Vec` implies 0 or more, so we stick to the meaning of the rust type. At least for me, I also rarely need a required with multiple occurrences argument but more often need optional with multiple occurrences. `Option<Vec<_>>` ends up matching `Vec<_>` which can raise the question of why have it. Some users might prefer the type. Otherwise, this is so users can detect whether the argument is present or not when using `min_values(0)`. Rather than defining an entire policy around this and having users customize it, or setting `min_values(0)` without the rest of a default policy, this gives people a blank slate to work from. Another design option would have been to not infer any special-type settings if someone sets a handful of settings manually, which would have avoided the confusion in Issue clap-rs/clap 2599 but I see that being confusing (for someone who knows the default, they will be expecting it to be additive; which flags disable inferred settings?) and brittle (as flags are added or changed, how do we ensure we keep this up?). Tests were added to ensure we support people customizing the behavior to match their needs. This is not solving: - `Vec<Vec<_>>`, see clap-rs/clap 2924 - `(T1, T2)`, `Vec<(T1, T2)>`, etc, see clap-rs/clap 1717 - `Vec<Option<_>>` and many other potential combinations Fixes clap-rs/clap 1772 Fixes clap-rs/clap 2599 See also clap-rs/clap 2195 |
||
---|---|---|
.. | ||
examples | ||
src | ||
tests | ||
Cargo.toml | ||
CONTRIBUTING.md | ||
LICENSE-APACHE | ||
LICENSE-MIT | ||
README.md |
clap_derive
Parse command line argument by defining a struct. It combines structopt and clap into a single experience. This crate is used by clap, and not meant to be used directly by consumers.
Documentation
Find it on Docs.rs. You can also check the examples and the changelog.
Example
Add clap
to your dependencies of your Cargo.toml
:
[dependencies]
clap = "3"
And then, in your rust file:
use std::path::PathBuf;
use clap::{Parser, ValueHint};
/// A basic example
#[derive(Parser, Debug)]
#[clap(name = "basic")]
struct Opt {
// A flag, true if used in the command line. Note doc comment will
// be used for the help message of the flag. The name of the
// argument will be, by default, based on the name of the field.
/// Activate debug mode
#[clap(short, long)]
debug: bool,
// The number of occurrences of the `v/verbose` flag
/// Verbose mode (-v, -vv, -vvv, etc.)
#[clap(short, long, parse(from_occurrences))]
verbose: u8,
/// Set speed
#[clap(short, long, default_value = "42")]
speed: f64,
/// Output file
#[clap(short, long, parse(from_os_str), value_hint = ValueHint::FilePath)]
output: PathBuf,
// the long option will be translated by default to kebab case,
// i.e. `--nb-cars`.
/// Number of cars
#[clap(short = 'c', long)]
nb_cars: Option<i32>,
/// admin_level to consider
#[clap(short, long)]
level: Vec<String>,
/// Files to process
#[clap(name = "FILE", parse(from_os_str), value_hint = ValueHint::AnyPath)]
files: Vec<PathBuf>,
}
fn main() {
let opt = Opt::parse();
println!("{:#?}", opt);
}
Using this example:
$ ./basic
error: The following required arguments were not provided:
--output <output>
USAGE:
basic --output <output> --speed <speed>
For more information try --help
$ ./basic --help
basic 0.3.0
Guillaume Pinot <texitoi@texitoi.eu>, others
A basic example
USAGE:
basic [OPTIONS] --output <output> [--] [file]...
ARGS:
<FILE>... Files to process
OPTIONS:
-c, --nb-cars <nb-cars> Number of cars
-d, --debug Activate debug mode
-h, --help Print help information
-l, --level <level>... admin_level to consider
-o, --output <output> Output file
-s, --speed <speed> Set speed [default: 42]
-V, --version Print version information
-v, --verbose Verbose mode (-v, -vv, -vvv, etc.)
ARGS:
<file>... Files to process
$ ./basic -o foo.txt
Opt {
debug: false,
verbose: 0,
speed: 42.0,
output: "foo.txt",
nb_cars: None,
level: [],
files: [],
}
$ ./basic -o foo.txt -dvvvs 1337 -l alice -l bob --nb-cars 4 bar.txt baz.txt
Opt {
debug: true,
verbose: 3,
speed: 1337.0,
output: "foo.txt",
nb_cars: Some(
4,
),
level: [
"alice",
"bob",
],
files: [
"bar.txt",
"baz.txt",
],
}
clap_derive rustc version policy
- Minimum rustc version modification must be specified in the changelog and in the travis configuration.
- Contributors can increment minimum rustc version without any justification if the new version is required by the latest version of one of clap_derive's dependencies (
cargo update
will not fail on clap_derive). - Contributors can increment minimum rustc version if the library user experience is improved.
Why
I've (@TeXitoi) used docopt for a long time (pre rust 1.0). I really like the fact that you have a structure with the parsed argument: no need to convert String
to f64
, no useless unwrap
. But on the other hand, I don't like to write by hand the usage string. That's like going back to the golden age of WYSIWYG editors. Field naming is also a bit artificial.
Today, the new standard to read command line arguments in Rust is clap. This library is so feature full! But I think there is one downside: even if you can validate argument and expressing that an argument is required, you still need to transform something looking like a hashmap of string vectors to something useful for your application.
Now, there is stable custom derive. Thus I can add to clap the automatic conversion that I miss. Here is the result.
License
Licensed under either of
- Apache License, Version 2.0 (LICENSE-APACHE or https://www.apache.org/licenses/LICENSE-2.0)
- MIT license (LICENSE-MIT or https://opensource.org/licenses/MIT)
at your option.
Contribution
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.