🗑️ Deprecate support for is_flag and flag_value parameters

[svlandeg]

Fixes #986

• Raise a DeprecationWarning when OptionInfo receives a value for is_flag and/or flag_value
• TyperOption doesn't use flag_value anymore and its is_flag is now defined only by looking at whether or not main_type is bool

These parameters weren't actually functional (cf. #873) and they weren't documented, so I don't think this should be breaking. But it's always difficult to say - users could be relying on unspecified internals... 🫤

[tiangolo]

Great! Looks good! 🚀 Thank you! 🙇

[Plenitude-ai]

Hello !
Sorry to come a bit late, we previously relied on another typer version (~0.12.5), and just changed for the newer (~0.15.0)
We did use the is_flag feature for handling boolean values with explicit values :

import typer


def main(my_bool: bool = typer.Option(True, is_flag=False)):
    print(f"my_bool : {my_bool}")
    print(f"type(my_bool) : {type(my_bool)}")


if __name__ == "__main__":
    typer.run(main)

Which could be used with :

> python main.py --my-bool true
my_bool : True
type(my_bool) : <class 'bool'>

OR :

> python main.py --my-bool false
my_bool : False
type(my_bool) : <class 'bool'>

For more details, we use argo workflows to submit scripts, therefore we cannot dynamically create the --my-bool or --not-my-bool string in the argo workflow template.
For the moment we implemented a workaround like :
my_bool = True if my_bool.lower()=="true" else False
But this forces the definition of the argument to be string in the signature, and then to cast it to bool, which is not the best.

I also thought of using alternative names
We could do something like :

def main(my_bool: bool = typer.Option(True, "--my-bool_true/--my-bool_false")):

And then :

> python main.py --my-bool_true

But this also becomes quite a strange use

This would be wonderful if we could get this feature back !

[twitthoefft]

Wanted to add support for @Plenitude-ai's comment. My team has the exact same use case and limitation about how bool values are dynamically created and passed as args.

[twitthoefft]

I think the original conclusion that is_flag was non-functional is incorrect. When the option type is bool, setting the is_flag=False parameter changes the default behavior of being flag-like to an Option that requires a passed argument.

In version 0.12.5 you can see this when checking --help as shown in the example above:

When is_flag is set to the default value of True the opposite flag argument --no-my-bool is created automatically.

 Usage: typertest.py [OPTIONS]                                               
                                                                             
╭─ Options ─────────────────────────────────────────────────────────────────╮
│ --my-bool    --no-my-bool      [default: my-bool]                         │
│ --help                         Show this message and exit.                │
╰───────────────────────────────────────────────────────────────────────────╯

But when is_flag is set to False the flag --no-my-bool is not created.

                                                                                 
 Usage: typertest.py [OPTIONS]                                                    
                                                                                  
╭─ Options ──────────────────────────────────────────────────────────────────────╮
│ --my-bool          [default: True]                                             │
│ --help             Show this message and exit.                                 │
╰────────────────────────────────────────────────────────────────────────────────╯

Failing to pass an argument to --my-bool now behaves like any other Option

╭─ Error ────────────────────────────────────────────────────────────────────────╮
│ Option '--my-bool' requires an argument.                                       │
╰────────────────────────────────────────────────────────────────────────────────╯

[svlandeg]

Thanks for your reports! Let me look into this (again) and get back to you 🙏