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

Prevent specifying global args multiple times #3938

Open
2 tasks done
cd-work opened this issue Jul 15, 2022 · 2 comments
Open
2 tasks done

Prevent specifying global args multiple times #3938

cd-work opened this issue Jul 15, 2022 · 2 comments
Labels
A-parsing Area: Parser's logic and needs it changed somehow. C-enhancement Category: Raise on the bar on expectations M-breaking-change Meta: Implementing or merging this will introduce a breaking change. S-waiting-on-design Status: Waiting on user-facing design to be resolved before implementing

Comments

@cd-work
Copy link

cd-work commented Jul 15, 2022

Please complete the following tasks

Clap Version

3.2.8

Describe your use case

When making an argument global with Arg::global(true), it will be available to both the parent and child subcommand. To me this implies that this option is a single flag that can be modified from anywhere.

However when specifying the global twice (e.g. cmd --global x subcmd --global y), the parent's assignment of the variable will be discarded in favor of the subcommand's. While this definitely is a possible way to handle this edgecase, I think this command invocation indicates that the user is doing something wrong and it would be better if clap could tell the user that what he's doing doesn't make any sense.

In my specific scenario, I have a command which defaults to one of it subcommands, so cmd --flag x is the same as cmd list --flag x, while there's also other subcommands like cmd foo --flag x. One flag is shared between all subcommands (which I've tried making global), while some others are only available to cmd and cmd list. This would solve the issue of having an option that can be specified twice for that one shared flag, but I'd still need another solution preventing people from using the other cmd list-specific flags which can also be used with just cmd when another subcommand like cmd foo is used. So it's possible that this feature request is just a band-aid rather than solving the root issue.

Describe the solution you'd like

Emit an error when specifying the same global argument multiple times.

Alternatives, if applicable

No response

Additional Context

No response

@cd-work cd-work added the C-enhancement Category: Raise on the bar on expectations label Jul 15, 2022
@cd-work
Copy link
Author

cd-work commented Jul 15, 2022

I'd still need another solution preventing people from using the other cmd list-specific flags which can also be used with just cmd when another subcommand like cmd foo is used. So it's possible that this feature request is just a band-aid rather than solving the root issue.

I've found the args_conflicts_with_subcommands option, so I guess that solves my root issue in a more general way. Though the error is rather... unfortunate.

@epage epage added the M-breaking-change Meta: Implementing or merging this will introduce a breaking change. label Jul 16, 2022
@epage
Copy link
Member

epage commented Jul 16, 2022

Just reading the description,

  • I would expect global arguments to be merged or overwritten based on their Action (granted, due to the current structure, we might not be able to handle this cleanly when custom actions are implemented).
  • Changing this would likely be considered a breaking change

@epage epage added A-parsing Area: Parser's logic and needs it changed somehow. S-waiting-on-design Status: Waiting on user-facing design to be resolved before implementing labels Nov 8, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-parsing Area: Parser's logic and needs it changed somehow. C-enhancement Category: Raise on the bar on expectations M-breaking-change Meta: Implementing or merging this will introduce a breaking change. S-waiting-on-design Status: Waiting on user-facing design to be resolved before implementing
Projects
None yet
Development

No branches or pull requests

2 participants