Skip to content
This repository has been archived by the owner on Jan 1, 2022. It is now read-only.

Why can't global args be required? #124

Open
epage opened this issue Dec 6, 2021 · 4 comments
Open

Why can't global args be required? #124

epage opened this issue Dec 6, 2021 · 4 comments

Comments

@epage
Copy link
Owner

epage commented Dec 6, 2021

Issue by gabbifish
Thursday Sep 12, 2019 at 23:53 GMT
Originally opened as clap-rs/clap#1546


Rust Version

rustc 1.36.0 (a53f9df32 2019-07-03)

Affected Version of clap

2.33.0

Bug or Feature Request Summary

I was hoping that I could make an argument required, and also use the global() function to ensure that a user of my CLI could specify my required option wherever they please.

Expected Behavior Summary

An Arg with both .global() and .required_unless() would be usable.

Actual Behavior Summary

I see

thread 'main' panicked at 'Global arguments cannot be required.

	'binding' is marked as global and required', /home/gabbi/.cargo/registry/src/github.com-1ecc6299db9ec823/clap-2.33.0/src/app/parser.rs:204:9

Steps to Reproduce the issue

Create a clap App with the arg below, and attempt to run it.

Sample Code or Link to Sample Code

                .arg(
                    Arg::with_name("binding")
                    .help("The binding of the namespace this action applies to")
                    .short("b")
                    .long("binding")
                    .value_name("BINDING NAME")
                    .takes_value(true)
                    .global(true)
                    .conflicts_with("namespace-id")
                )
@epage
Copy link
Owner Author

epage commented Dec 6, 2021

Comment by jamestwebber
Wednesday Oct 23, 2019 at 20:02 GMT


I'll +1 this issue, I would like this to work as well. My tool has a bunch of universal required arguments (e.g. input directory) and then different tasks have some specific options. I was hoping to have usage look like

cmd --input [dir] --cmd-specific-option [option]
cmd subcmd --input [dir] --subcmd-specific-option [option]

Where --input is always required but can be specified after subcmd for readability (I find that dropping a subcommand in the middle of the line is hard to use/read).

Maybe there's a better way to set this up?

@epage
Copy link
Owner Author

epage commented Dec 6, 2021

Comment by erayerdin
Wednesday Jun 02, 2021 at 06:45 GMT


I don't know why this is the case, but a workaround now would be defining a .default_value("whatever") and do whatever when you get whatever as value.

This is one way, however one should keep in mind that this default value also limits what can be done with value. In my case, I will use an arg as Telegram token value, which is a long string, so setting default to "INVALID" makes sense in my case because I'm fairly sure there won't be any bot token with value "INVALID". On the other hand, if I used that arg as a file path, that would eliminate a directory or file named "INVALID".

Wish this will be implemented soon.

@epage
Copy link
Owner Author

epage commented Dec 6, 2021

Comment by pksunkara
Thursday Jun 03, 2021 at 19:34 GMT


I would welcome people to design how this should work and implement it. Unfortunately, as it is now, we have no design to implement this because the global arg gets propagated to all subcommands and we haven't yet decided on how to resolve the required situation when that happens.

@epage
Copy link
Owner Author

epage commented Dec 6, 2021

Comment by jplatte
Monday Nov 01, 2021 at 15:54 GMT


Until this is supported, maybe the derive macro could raise an error when #[clap(global = true)] is used on a required setting?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant