-
-
Notifications
You must be signed in to change notification settings - Fork 1.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
arg_required_else_help
does not show help when env variables are present
#3572
Comments
#3421 changed In #2950, we discussed how we should handle env variables and it was proposed that we treat them like user supplied values. So the questions for this issue
@pksunkara since you were involved in the past discussion, I'd be curious to know what your thoughts are? I think showing |
Got ahead of myself on this. The intention was to be explicit about a subcommand being required when args are present but not a subcommand rather than the user having to infer that from the help message. So if we did anything with this option, we'd have to explicitly check for if any CLI args are present. |
Thanks for the response!
The best option might just be to let the user decide, which would also avoid a breaking change. Leave the default as it is, and add a The main issue right now is that I have no way to distinguish whether a user typed anything after In general, I'd also expect a user-supplied arg to take precedence over one provided from ENV, which I believe is the current behavior. |
We are trying to limit the amount of configuration we provide. The more configuration, the more cases we have to be documented and tested, and the worse our build times and code size are. It also becomes overwhelming in the documentation, making it hard to be aware of what features clap has. We are working on reducing the amount of configuration we have at this point.
To double check, your concern is with what error we show the user? The difference in error messages is enough to avoid that message? |
No, the behavior I want (shown in expected output in the issue above) is for
This makes sense and I definitely understand. I just wish there was some way to achieve the previous functionality of |
Sorry, I was speaking for a clap internals perspective: those are both error messages. |
.arg_required_else_help().subcommand_required()
does not replicate SubcommandRequiredElseHelp with env variables
Clues here: clap-rs/clap#3572
I ran into this with the derive API. Now that the deprecated feature was removed in clap v4, it seems Agree that when a required subcommand is missing, the list of possible subcommands should be shown. If this is a breaking change, adding a configuration option and changing the behavior in the next major version seems like the only path forward. Edit: though perhaps missing or invalid arguments should have precedence over a missing subcommand. So that the CLI can be explored like this:
This way at step 3 the user will know that they are passing the correct arguments and can proceed to choosing a subcommand. |
Mixing a required
The user made a best effort and it still failed. We should be more specific about what failed rather than sending them back to the beginning with help. We could prefix help with a message but that will most likely get lost in the noise. |
I'm thinking of environment variables, specifically database or other credentials needed for a collection of similar operations.
Sorry, I meant that it shows the list of subcommands that can follow after Getting a help message with new information instead of an error seems like an intuitive sign of progress. |
Shows the list of subcommands or shows the help? Maybe we are using terms slightly differently but its not clear to me what you are looking for. As a possible guess as to what you mean, some similar cases
Similarly, for required subcommands, we could show all of the available subcommands in the error message when one is missing. |
Yeah, showing the list of subcommands in the error would fix the main problem: that the user needs to type another shell command just to look at the list. Another reason I prefer help here is that it looks more consistent in a tree of subcommands: it's weird that between |
Similar to - Listing all required arguments when one is missing - Listing all possible values when no value is provided This came up when discussing clap-rs#3572
a little different understanding here, when When the env function is not used, he works normally and does show the help message, the |
.arg_required_else_help().subcommand_required()
does not replicate SubcommandRequiredElseHelp with env variablesarg_required_else_help
does not show help when env variables are present
Please complete the following tasks
Rust Version
rustc 1.58.1 (db9d1b20b 2022-01-20)
Clap Version
clap = { version = "3.1.6", features = ["env", "std", "cargo"] }
Minimal reproducible code
Cargo.toml
src/broken.rs
src/working.rs
src/deprecated-working.rs
Steps to reproduce the bug with the above code
src/deprecated-working.rs
src/working.rs
src/broken.rs
Actual Behaviour
When I use
.env("ENV_VAR")
on anArg
, and I have.subcommand_required(true).arg_required_else_help(true)
, andENV_VAR
is set, help is not output, instead a short usage message appears without help.This is what happens:
src/broken.rs
Expected Behaviour
When I use
.env("ENV_VAR")
on anArg
, and I have.subcommand_required(true).arg_required_else_help(true)
, andENV_VAR
is set, help should be output, instead of a short usage message without help.This is what should happen:
src/deprecated-working.rs
Said another way, **I should be able to emulate the behavior of
AppSettings::SubcommandRequiredElseHelp
without using a deprecated setting.Additional Context
Maybe this is a new builder setting;
.subcommand_required_else_help()
, or perhaps.env_provides_user_arg(false)
, or similar.Awesome work on Clap btw :)
Debug Output
src/broken.rs
src/working.rs
src/deprecated-working.rs
The text was updated successfully, but these errors were encountered: