Skip to content
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 global args in top-level multicall #4521

Open
2 tasks done
jaskij opened this issue Nov 29, 2022 · 4 comments
Open
2 tasks done

Allow global args in top-level multicall #4521

jaskij opened this issue Nov 29, 2022 · 4 comments
Labels
A-builder Area: Builder API C-enhancement Category: Raise on the bar on expectations S-waiting-on-decision Status: Waiting on a go/no-go before implementing

Comments

@jaskij
Copy link

jaskij commented Nov 29, 2022

Please complete the following tasks

Clap Version

4.0.27

Describe your use case

When writing a multicall program, I have some options that I'd like to be available to all commands. In addition, to reduce boilerplate, I would like them to be in the top-level struct.

A prime example of this would be log level, which is set once, just after parsing the commandline, before entering a specific subcommand.

Describe the solution you'd like

This looks good enough - as is, this is rejected by debug asserts.

#[derive(Debug, clap::Parser)]
#[command(multicall(true))]
struct Cli {
    #[command(subcommand)]
    command: Command,

    #[arg(global = true)]
    log_level: LogLevel,
}

Alternatives, if applicable

A workaround would be to add the log level enum as an option on all subcommands - doable, but seems to require some amount of repetitive code, which is always an issue when it comes to later changes.

The amount of repetition could perhaps be eased by using a declarative macro, but those are somewhat annoying to write and not everyone is comfortable with them.

Additional Context

No response

@jaskij jaskij added the C-enhancement Category: Raise on the bar on expectations label Nov 29, 2022
@epage epage added S-waiting-on-decision Status: Waiting on a go/no-go before implementing A-builder Area: Builder API labels Nov 29, 2022
@epage
Copy link
Member

epage commented Nov 29, 2022

When I prevented arguments on the multicall command, I was trying to balance

  • Correct parsing behavior (ie disallowing $ --verbose cmd)
  • Correct $ help behavior (not showing arguments)
  • Minimal binary size impact
    • At the moment, I would classify this a small scope feature (few people would use it) which means we prioritize binary size over conveniences.

It would be nice to support global arguments but any solution should maintain the above balance unless we find a reason to re-evaluate our priorities for this feature.

@paulyoung

This comment was marked as off-topic.

@epage

This comment was marked as off-topic.

@paulyoung

This comment was marked as off-topic.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-builder Area: Builder API C-enhancement Category: Raise on the bar on expectations S-waiting-on-decision Status: Waiting on a go/no-go before implementing
Projects
None yet
Development

No branches or pull requests

3 participants