| single |
jsonargparse
============
Docs: https://jsonargparse.readthedocs.io/ | Source:
https://github.com/omni-us/jsonargparse/
jsonargparse is a library for creating command-line interfaces (CLIs) and
making Python apps easily configurable. It is a well-maintained project
with
frequent releases, adhering to high standards of development: semantic
versioning, deprecation periods, changelog, automated testing, and full
test
coverage.
Although jsonargparse might not be widely recognized yet, it already boasts
a [substantial user base
]. Most notably,
it serves as the engine behind [LightningCLI
].
Features
--------
jsonargparse is user-friendly and encourages the development of **clean,
high-quality code**. It encompasses numerous powerful features, some unique
to
jsonargparse, while also combining advantages found in similar packages:
- **Automatic** creation of CLIs, like [Fire
], [Typer
], [Clize
] and [Tyro
].
- Use **type hints** for argument validation, like [Typer
], [Tap
] and [Tyro
].
- Use of **docstrings** for automatic generation of help, like [Tap
], [Tyro
] and [SimpleParsing
].
- Parse from **configuration files** and **environment variables**, like
[OmegaConf], [dynaconf
], [confuse
] and [configargparse
].
- **Dataclasses** support, like [SimpleParsing
] and [Tyro
].
Other notable features include:
- **Extensive type hint support:** nested types (union, tuple, etc.),
containers (list, dict, etc.), restricted types (regex, numbers), paths,
URLs,
types from stubs (``*.pyi``), future annotations (PEP [563
]), and backports (PEPs [604
]/[585
]).
- **Dependency injection:** support types that expect a class instance and
callables that return a class instance.
- **Structured configs:** parse config files with more understandable
non-flat
hierarchies.
- **Config file formats:** [json], [yaml
], [jsonnet] and extendible to
more formats.
- **Relative paths:** within config files and parsing of config paths
referenced
inside other configs.
- **Argument linking:** directing parsed values to multiple parameters,
preventing unnecessary interpolation in configs.
Design principles
-----------------
- **Non-intrusive/decoupled:**
There is no requirement for unrelated modifications throughout a
codebase,
maintaining the [separation of concerns principle
]. In simpler terms,
changes should make sense even without the CLI. No need to inherit from a
special class, add decorators, or use CLI-specific type hints.
- **Minimal boilerplate:**
A recommended practice is to write code with function/class parameters
having
|