CLI Inconsistency With --tls-verify

[0x0D15]

It seems that the buildah login's --tls-verify flag requires an equals to pass an argument to whereas every other flag does not.

I.e. every other flag supports --flag argument without needing to specify --flag=argument

[Luap99]

That is expected, --tls-verify is a bool flag that does not accept a value. You can only set true or false. this isn't special to the tls-verify flag, there are lot more like this.

For --flag argument the parser has no idea if the argument is for the flag or the command otherwise so this behavior cannot be changed without breaking the existing usage.

But I agree the buildah does don't really seem to explain that so I guess docs patches welcome

[0x0D15]

Gotcha, however I didnt fully understand why this behavior can't be changed; what's stopping --tls-verify false and --tls-verify=false from both working?

For --flag argument the parser has no idea if the argument is for the flag or the command otherwise so this behavior cannot be changed without breaking the existing usage

Wouldnt this be the case for every flag? Many of which do work without an equals sign.

[Luap99]

what's stopping --tls-verify false and --tls-verify=false from both working? Wouldnt this be the case for every flag? Many of which do work without an equals sign.

No because a flag with an argument has a required argument, i.e. buildah build --network <value> always parses value for the network flag because it is an required argument. For a bool flag that is different the --tls-verify on its own without extra argument is valid and gets treated as true. The parser doesn't know if the following argument then refers to the bool flag or the command itself. As such it always considers it part of the command.

We are using the pflag library to parse this, there are some more examples here https://github.com/spf13/pflag?tab=readme-ov-file#setting-no-option-default-values-for-flags

[0x0D15]

For a bool flag that is different the --tls-verify on its own without extra argument is valid and gets treated as true

Understood; so the "fix" in this case would be to stop using default value flags and always mandate an argument which I suppose would be a breaking change. (Although this would be ideal/intuitive from my view i.e. no-flag is the default value and with a flag an argument is required).

[Luap99]

which I suppose would be a breaking change

yes because it would also make just --tls-verify without arg impossible so this is not something we would ever want to do I think. --tls-verify isn't the best example because it generally defaults to true already so a user must do --tls-verify=false explicitly. But for most bool option we have they default to false so setting just the option is enough.

i.e. for build there a many bool vars which default to false where just setting them as is without arg makes perfect sense all-platforms, compress, compat-volumes, no-cache, no-hostname, no-hosts, quiet and more

[github-actions[bot]]

A friendly reminder that this issue had no activity for 30 days.