Spike --dry-run flag as a string instead of a bool #346
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This morning Steve was bitten by the old CLI boolean-argument gotcha
(see https://docs.kosli.com/faq/#boolean-flags)
He suggested we could:
--dry-runflag 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:
"false"if no flag is explicitly provided at all.This should be possible.
"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=Xwith a value oftrue/falsefor X is a Good Thing and actually better than allowing a default of"true"when they just write--compliant.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--assertflags in thekosli attest pullrequestcommands.--compliantinkosli 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/falsethen splice it into the previous argument with an=?