-
-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Allow literal and dynamic values for version in clap_derive #3034
Comments
Put the above into a repo in case a full repro is more useful: https://github.com/gibfahn/clap_repro |
I think it works with |
Ahh, you're right @mkayaalp , that does work. But yeah, same question, isn't this supposed to be the default? |
In structopt, the way you opt-out of automatic version detection is with a Looks like this was changed in My guesses
I am personally torn on this. Being more explicit has its benefits but requiring everyone to know a set of attributes they need to se is a pain (e.g. see the discussion on changing App defaults). |
Even if we keep this, we should make all example code specify |
I think I like the following snippet from that commit. Maybe it should be in the #[derive(Clap, Debug)]
#[clap(author, about, version)]
// ^^^^^^ <- derive author from Cargo.toml
// ^^^^^ <- derive description from Cargo.toml
// ^^^^^^^ <- derive version from Cargo.toml
struct Opt {} |
Probably too detailed for high level examples but we should defintely talk about it where we break down all of the "magic" methods (methods derived from attributes after some post-processing by us) |
There is already an example with explicit version and author attributes (for top-level and subcommand). Top-level could be changed to show #[derive(Parser)]
#[clap(version = "1.0", author = "Kevin K. <kbknapp@gmail.com>")]
struct Opts {
//...
#[clap(subcommand)]
subcmd: SubCommand,
}
#[derive(Parser)]
enum SubCommand {
#[clap(version = "1.3", author = "Someone E. <someone_else@other.com>")]
Test(Test),
} |
I think the discussion was a lot fragmented, some of it happening on structopt and some of it on clap.
Yup. Especially when we had
Exactly this too. Even in normal API, we explicitly ask the author to specify
Also this, Apparently it had some issues with parsing and stuff in structopt. But I am not exactly clear on what they were.
I think this can be solved by what you said in the other comment regarding documentation.
I am tagging this for 3.1 milestone because we want to support literal and dynamic values for this method too. Similar to subcommand name in #2751 |
I was with you until the end there. The issue was not that The issue was the version not being set without the I think the "magic" about the |
You are right. I misunderstood part of the issue being that dynamic values not working right now. My bad. |
Folks getting started with clap are likely to want to use the automatic version and author parsing initially. Hopefully those who do want to hard-code a value will note that that can be done as well from the SubCommand version parameter. Refs: clap-rs#3034
Folks getting started with clap are likely to want to use the automatic version and author parsing initially. Hopefully those who do want to hard-code a value will note that that can be done as well from the SubCommand version parameter. Refs: clap-rs#3034
Please complete the following tasks
Rust Version
rustc 1.56.1 (59eed8a2a 2021-11-01)
Clap Version
3.0.0-beta.5
Minimal reproducible code
Steps to reproduce the bug with the above code
By default the version in the Cargo.toml is not picked up. The
--help
command doesn't show the version, and the--version
command fails.If you uncomment the version line below things start to work.
Actual Behaviour
Version must be manually set.
Expected Behaviour
With structopt the version is picked up automatically:
Additional Context
Sorry if this was an intentional change, I didn't see anything in the docs about it.
Debug Output
Debug output of
--version
Debug output of
--version
The text was updated successfully, but these errors were encountered: