tyro

tyro.cli() is a tool for generating CLI interfaces.

We can define configurable scripts using functions:

"""A command-line interface defined using a function signature.

Usage: python script_name.py --foo INT [--bar STR]
"""

import tyro

def main(
    foo: int,
    bar: str = "default",
) -> None:
    ...  # Main body of a script.

if __name__ == "__main__":
    # Generate a CLI and call `main` with its two arguments: `foo` and `bar`.
    tyro.cli(main)

Or instantiate config objects defined using tools like dataclasses, pydantic, and attrs:

"""A command-line interface defined using a class signature.

Usage: python script_name.py --foo INT [--bar STR]
"""

from dataclasses import dataclass
import tyro

@dataclass
class Config:
    foo: int
    bar: str = "default"

if __name__ == "__main__":
    # Generate a CLI and instantiate `Config` with its two arguments: `foo` and `bar`.
    config = tyro.cli(Config)

    # Rest of script.
    assert isinstance(config, Config)  # Should pass.

Other features include helptext generation, nested structures, subcommands, and shell completion. For examples and the API reference, see our documentation.

In the wild

tyro is designed to be lightweight enough for throwaway scripts, while facilitating type safety and modularity for larger projects. Examples:

Alternatives

tyro is an opinionated library. If any design decisions don't make sense, feel free to file an issue!

You might also consider one of many alternative libraries. Some that we particularly like:

• simple-parsing and
  jsonargparse, which provide deeper
  integration with configuration file formats like YAML and JSON.
• clipstick, which focuses on
  generating CLIs from Pydantic models.
• datargs, which provides a minimal API for
  dataclasses.
• fire and
  clize, which support arguments without type
  annotations.

We also have some notes on tyro's design goals and other alternatives in the docs here.