-
-
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
Args/Subcommand app settings shouldn't impact what they are flattened into #2894
Comments
Note: we can't just move the app method calls to Options
|
In thinking about this, it might make sense for |
In #2983 I made this comment
|
After having had time with this in various scenarios, I feel like any solution for this will end up being worse than the problem. |
Please complete the following tasks
Rust Version
rustc 1.55.0 (c8dfcfe04 2021-09-06)
Clap Version
master
Minimal reproducible code
Steps to reproduce the bug with the above code
cargo run -- --help
Actual Behaviour
Expected Behaviour
Additional Context
With the vocabulary we are providing users, we are
flatten
ing anArgs
. This says nothing about flattening anApp
as well.This has also led to a series of bugs like #2527. We've worked around this by carefully setting the precedence (TeXitoi/structopt#325, #2531 and #2819) which has lead to other bugs like #2785 which required more precedence tweaks (#2882).
By distinguishing what app settings are tightly associated with flattening (help_heading, the implicit subcommand required else help) and making everything else only apply when creating an App, we can simplify, clarify, and make less brittle these relationships.
Debug Output
No response
The text was updated successfully, but these errors were encountered: