-
Notifications
You must be signed in to change notification settings - Fork 27
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
More flexibility to the core parsing API #34
Comments
Thanks for giving the library a try!
Does that all make sense? |
Thanks for quick response, I'll submit a PR soon for (2). |
Hi! Just wanted to start off by saying that the library looks great 🎉. I'm trying to assess the feasibility of Tyro for my use-case, and there are a couple suggestions that maybe you'd consider:
It would be great to have more flexibility to get the parsed arguments without calling the function. I was thinking potentially having a function that returns something like
inspect.BoundArguments
after parsing is complete. This way we can have more flexibility on how we call the function.Another possibility might be an API where you don't provide a function, but just a dataclass that'll get hydrated from the CLI.EDIT: I see now that you can parse a dataclass usingtyro.cli
.It would be great if there was a flag like
strict
that controls whether argparse attempts to parse all arguments or only known arguments. For example, you could parse known arguments with Tyro then default back to absl to parse Jax config flags. To accomplish this, you'd need some way of knowing what Tyro wasn't able to parse. This is somewhat possible already by doing:_, unknown_args = tyro.extras.get_parser(f).parse_known_args()
unknown_args
fromsys.argv
and parse these separately.tyro.cli(f, args=...)
with the filtered args.It would be nice if there was an easier way to perform this. Perhaps this could be specifically added to (1) where if you specify
strict=False
it'll return a tupleBoundArguments, List[str]
where the second element is the unknown arguments.A crazy feature that might be useful to others is if there was a way to go from a dataclass instance (or annotation of a dataclass) to the (minimal?) CLI arguments needed to generate that dataclass. e.g., something like
tyro.extras.to_cli_args
. The use-case here is to keep all your configs / sweeps in Python, this would be specifically useful for sweeps. You could have a generator over (annotated?) dataclasses and then convert those to CLI arguments when launching a job.The text was updated successfully, but these errors were encountered: