-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Confusion around managing flags like --version
#132
Comments
Hi, thanks for filing this issue! I'm working on a deadline right now and will be mostly offline until ~Friday (I can follow up after if you have questions), but here are some initial thoughts. In general I think (1) (2)
Unfortunately, I don't think there's an alternative behavior that makes sense. When passed a type like In this case, the Python constructor has specified:
To me this seems reflected 1:1 in the behavior of the CLI you've generated. We just need to put a value in for For how to achieve the behavior you want: I can think about it but specifying that there's a set of subcommands that are optional only when (3)
The error message is saying that the argument is not recognized in its current location, and in particular it might be misplaced. The Open to suggestions if you have ideas on how to clarify! (4)
This is happening because you've annotated |
Hey, thanks for the detailed response and for going through my message. I understand there are some limitations and I'd be more than happy to help with PR's if you want to land on a desired behavior for Tyro around this.
Ultimately, I want to pass flags that behave like Let me know if you have an idea of how can this be achieved! Thanks! |
Thanks for the offer! I can think about it, but I'm not sure this is well-supported even in more expressive libraries like If you want a hacky solution one option is to check |
How to add the help text in this case though...? |
I've been impressed with Tyro's capabilities so far. However, I've encountered some ergonomic challenges that I hope to get some help with.
Related Issue: This issue seems to be related to issue #89. Although I attempted the solutions suggested there, I was unable to resolve my problem.
The Problem:
I'm in the process of creating a CLI with two subcommands: init and run. Each subcommand requires its own set of arguments. Additionally, I want the CLI to accept global flags such as --version or --status. Here's my initial setup:
Initial Setup
Running cli.py --help displays the help text as expected. However, I've noticed that the
--no-version
flag is automatically generated and doesn't align with my requirements. I am looking for a way to disable this automatic generation.Moreover, when I attempt to use the
--version
flag independently, it doesn't function as anticipated:This command incorrectly demands a subcommand (init or run), which should not be the case for a version check.
When running
--version
under one of the subcommands, an error is thrown out, which makes sense but the error doesn't.(.venv) python cli.py init --version ╭─ Unrecognized options ───────────────────────╮ │ Unrecognized or misplaced options: --version │ │ ──────────────────────────────────────────── │ │ Perhaps you meant: │ │ --version, --no-version │ │ (default: False) │ │ in cli.py --help │ │ ──────────────────────────────────────────── │ │ For full helptext, run cli.py --help │ ╰──────────────────────────────────────────────╯
Optional Subcommands
To work around this, I tried making the subcommand optional:
Applying an
Optional
type with default value =None
allows--version
to be run by itself but also appends a subcommandNone
option, which doesn't make sense in this case.Regarding #89, I've tried modifying the alternatives stated here and here with no success.
1st try
2nd try
I'm confused here. Not sure if I'm misunderstanding something from the documentation or how to apply different options, but seems that applying flags that i) do not create
--no-x
versions and ii) can be applied alone outside any command, should be fairly straightforward on a CLI tool.Thanks!
The text was updated successfully, but these errors were encountered: