[FEATURE] Handling Mutliple Variable Length Arguments

[rmorshea]

I'm not familiar with the internals of typer and whether this is feasible, but it would be nice if it were possible to implement a command like the following:

from typing import Optional, List

import typer

app = typer.Typer()


@app.command()
def main(first_list: List[str], option: bool = False, second_list: List[str] = ()):
    print(first_list, second_list)

Where the expected behavior is:

$ python main.py a b c --option d e f
('a', 'b', 'c') ('d', 'e', 'f')
$ python main.py a b c d e f --option
('a', 'b', 'c', 'd', 'e', 'f') ()
$ python main.py a b c d e f
('a', 'b', 'c', 'd', 'e', 'f') ()

However the actual behavior in this case does not adhere to the above:

$ python main.py a b c --option d e f
('a', 'b', 'c', 'd', 'e', 'f') True ()

This can presently be achieved in argparse quite concisely:

import argparse

def main():
    cli = argparse.ArgumentParser()
    cli.add_argument(
        "first_list", nargs="*", type=str,
    )
    cli.add_argument(
        "--option", nargs="*", type=str, default=[],
    )
    args = cli.parse_args()
    print(args.first_list, args.option)

[IamCathal]

Hey,

In the docs it gives an example as to how you can use multiple values for one argument (such as a list). It involves using the argument name as a flag before each new element like this:

python main.py --first John --first Mary --second Liam --second Sean

Without the flag before each one it won't pick it up.
I wasn't able to properly run the call that gave your actual output which was:

python main.py a b c --option d e f

as it shouldn't be valid due to the reason listed above.

Calling the script pasted below
python main.py --first Michael --first Liam with and without the --option flag
gives me the output
('Michael', 'Liam') ()
which seems to be what you're trying to achieve. Is this the problem you were encountering or am I misinterpreting you?

from typing import Optional, List

import typer

option = False



def main(first: List[str] = typer.Option(None), 
        option: bool = False, 
        second: List[str] = typer.Option(None)):
    print(first, second)

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

[tiangolo]

Thanks for the help here @IamCathal ! 🚀 🍰

Yeah, it's a constraint in Click: https://click.palletsprojects.com/en/7.x/options/#multi-value-options

For options, only a fixed number of arguments is supported.

To declare a fixed number of arguments for a CLI option you can use tuples: https://typer.tiangolo.com/tutorial/multiple-values/options-with-multiple-values/

[github-actions]

Assuming the original issue was solved, it will be automatically closed now. But feel free to add more comments or create new issues.

[alsimoneau]

I feel like this issue isn't solved.

The original post mention that this would be an appreciated feature that is supported by others.
Stating that it is not supported is in no way an answer as that is the point of the issue.

I also have a use case where that feature would be useful.
When passing wildcards to the option, bash automatically expands them. This makes the use of the program unintuitive since the user must pass the parameter as a string and the software then needs to reexpand it.

Yes, one could use an argument, but when multiple such file lists are needed, it is impossible. Supporting nargs=-1 on options completely solves this issue.

[schuhschuh]

I second @alsimoneau. I recently discovered and switched from argparse to Typer and enjoy writing CLIs using it. However, the lack of support for multiple arguments of non-fixed length (for which fixed length Tuple annotation can be used) without need to prepend each value with an option key is a limitation which eventually may make me move back to argparse rather.

EDIT: However, checking the latest documentation of Click, it seems this limitation remains and unsure how Typer could work around this limitation. "For options, only a fixed number of arguments is supported."

[fabio-porcedda]

The lack of this feature prevents me to pass from argparse to Typer for my script.

[riyadparvez]

Is there any progress on this issue? This is the only thing that's been stopping me from using typer

[miska-ship-it]

Seconding (thirding?) the need/want for this

[gustavorps]

+1

[dromer]

Oof this is actually a big reason to stick to argparse for me. Was looking at migrating https://github.com/Wasted-Audio/hvcc to Typer but this really is inconvenient.

[Rocamonde]

If this is not going to be fixed / supported, a maintainer should explain why and label the issue accordingly, so that users can decide what tool works best for their needs. Otherwise, it should be reopened.

[alsimoneau]

I feel that the maintainers are not looking at closed issues.
It may be a good idea to open a new one referencing this to bring their attention to the issue.