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

fix!: Require explicit help/version disabling #4056

Merged
merged 1 commit into from Aug 11, 2022
Merged

Conversation

epage
Copy link
Member

@epage epage commented Aug 11, 2022

Before we introduced actions, it required specific setups to engage with
claps version and help printing. With actions making that more
explicit, we don't get as much benefit from our multiple, obscure, ways
of users customizing help

Before

  • Modify existing help or version with mut_arg which would
    automatically be pushed down the command tree like global(true)
  • Create an new help or version and have it treated as if it was the
    built-in on (I think)
  • Use the same flags as built-in and have the built-in flags
    automatically disabled
  • Users could explicitly disable the built-in functionality and do what
    they want

Now

  • mut_arg no longer works as we define help and version flags at the
    end
  • If someone defines a flag that overlaps with the built-ins by id,
    long, or short, a debug assert will tell them to explicitly disable
    the built-in
  • Any customization has to be done by a user providing their own. To
    propagate through the command tree, they need to set global(true).

Benefits

  • Hopefully, this makes it less confusing on how to override help
    behavior. Someone creates an arg and we then tell them how to disable
    the built-in
  • This greatly simplifies the arg handling by pushing more
    responsibility onto the developer in what are hopefully just corner
    cases
  • This removes about 1Kb from .text

Fixes #3405
Fixes #4033

Before we introduced actions, it required specific setups to engage with
claps version and help printing.  With actions making that more
explicit, we don't get as much benefit from our multiple, obscure, ways
of users customizing help

Before
- Modify existing help or version with `mut_arg` which would
  automatically be pushed down the command tree like `global(true)`
- Create an new help or version and have it treated as if it was the
  built-in on (I think)
- Use the same flags as built-in and have the built-in flags
  automatically disabled
- Users could explicitly disable the built-in functionality and do what
  they want

Now
- `mut_arg` no longer works as we define help and version flags at the
  end
- If someone defines a flag that overlaps with the built-ins by id,
  long, or short, a debug assert will tell them to explicitly disable
  the built-in
- Any customization has to be done by a user providing their own.  To
  propagate through the command tree, they need to set `global(true)`.

Benefits
- Hopefully, this makes it less confusing on how to override help
  behavior.  Someone creates an arg and we then tell them how to disable
  the built-in
- This greatly simplifies the arg handling by pushing more
  responsibility onto the developer in what are hopefully just corner
  cases
- This removes about 1Kb from .text

Fixes clap-rs#3405
Fixes clap-rs#4033
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
1 participant