Skip to content

Conversation

@JonJagger
Copy link
Contributor

@JonJagger JonJagger commented Oct 7, 2024

This morning Steve was bitten by the old CLI boolean-argument gotcha
(see https://docs.kosli.com/faq/#boolean-flags)
He suggested we could:

  • make the --dry-run flag a string variable.
    I've done a quick s/!global.DryRun/global.DryRun == "false"/ and a few other mods and this works as expected and gets us support for joining with a space (--dry-run true) and joining with an equal (--dry-run=true) when the flag is explicitly provided.

The crucial bits are:

  • default it to "false" if no flag is explicitly provided at all.
    This should be possible.
  • default it to "true" (the opposite!) if the flag is explicitly provided, but with no value.
    I suspect we will struggle to support this. If we can't it would be a breaking change.
    A point of view here is that forcing customers to explicitly provide --compliant=X with a value of true/false for X is a Good Thing and actually better than allowing a default of "true" when they just write --compliant.
  • limit these "bool-string" values to "true" and "false"
    Maybe this would be useful ? Add capability to restrict flag values to a set of allowed values spf13/pflag#236 (comment)

Other boolean flags:

  • --debug
  • --assert flags in the kosli attest pullrequest commands.
  • --compliant in kosli attest generic. This is the one that has caught me out in the past, actually caught Steve out this time, and seems to catch customers out too.

Would it be possible to examine argv before any parsing takes place and if there is a lone true/false then splice it into the previous argument with an = ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants