-
Notifications
You must be signed in to change notification settings - Fork 156
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
Update arg parsing to clap v3 #183
Conversation
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.
Thanks for working on this! In order to make this easy to review, I'd like to have just the minimal changes required to get it compiling with clap, and then have a follow-up PR (or follow-up commits in this PR) to further improve the command-line parsing.
Also could you please elaborate with some examples on things that are now allowed or are no longer allowed with regards to the argument parsing?
pid: Option<u32>, | ||
|
||
/// Generate shell completions for the given shell. | ||
#[structopt(long = "completions", conflicts_with = "pid")] | ||
completions: Option<structopt::clap::Shell>, | ||
#[clap(long, value_name = "SHELL", conflicts_with_all = &["pid", "trailing-arguments"])] |
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.
Why spell out the value_name
here?
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 describes what we're actually specifying, i.e. the target shell, otherwise clap just copies the field name
graph: flamegraph::Options, | ||
|
||
#[structopt(parse(from_os_str), long = "perfdata", conflicts_with = "pid")] | ||
#[clap(long = "perfdata", conflicts_with = "pid", parse(from_os_str))] |
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.
Is reordering necessary here or just a style tweak?
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.
The latter
Thank you for having me! 😄 As for the new things, clap 3 mostly just cleans up all the APIs and incorporates old structopt under the Among the more interesting new additions is the use clap::ArgEnum;
#[derive(ArgEnum)]
enum ProcessingMode {
Batch,
Interactive,
}
#[derive(Parser)]
struct Cli {
#[long, arg_enum]
mode: ProcessingMode,
} This would accept args like |
I went ahead and disabled the CLI portion of |
I seem to have missed the point of your question, I'm assuming you were asking about the breaking changes I introduced. Now that the cargo flamegraph -F 10000 -- --my --args -a -b -c This is slightly more restrictive, but also now the user unambiguously knows how to pass any arguments to their own application. |
Thanks! |
Slightly breaking change: trailing arguments are now marked as
last
i.e. they have to be put after a--
marker, which seems to be more manageable/reasonable.