pyrig – Production-ready Python project infrastructure in three commands
I built pyrig to stop spending hours setting up the same project infrastructure repeatedly.
uv init
uv add pyrig
uv run pyrig init
You get: source structure with a Typer CLI, pytest with 90% coverage enforcement, GitHub Actions (CI, release, deploy), MkDocs site, git hooks, Containerfile, and all the config files — pyproject.toml, .gitignore, branch protection, issue templates, everything for a full Python project.
Ships with all of Astral's tools (uv, ruff with all rules enabled, ty), plus pytest-cov, bandit, pip-audit, rumdl, prek, MkDocs Material, and Podman. Everything is pre-configured and wired into CI/CD and git hooks from the start.
The interesting part is what happens after scaffolding.
pyrig isn't a one-shot template generator. Every config is a Python class. Running "pyrig mkroot" regenerates and validates all configs — merging missing values without removing your customizations. Change your project description in pyproject.toml, rerun, and it propagates to your README and docs. Fully idempotent.
pytest enforces project correctness. 11 autouse session fixtures run before your tests: they verify every source module has a corresponding test file (auto-generating skeletons if missing), that no unittest usage exists, that src/ doesn't import from dev/, that there are no namespace packages, and that configs are up to date. You can't get a green test suite with a broken project structure.
Zero-boilerplate CLIs. Any public function in subcommands.py becomes a CLI command automatically — no decorators, no registration:
my_project/dev/cli/subcommands.py
def greet(name: str) -> None:
"""Say hello."""
print(f"Hello, {name}!")
$ uv run my-project greet --name World
Hello, World!
Automatic test generation. Add a new file my_project/src/utils.py, run pytest, and tests/test_my_project/test_src/test_utils.py appears with a NotImplementedError stub so you know what still needs writing. Customizable via subclassing.
Config subclassing. Want a custom git hook? Subclass PrekConfigFile, call super(), append your hook. pyrig discovers it automatically — the leaf class in the dependency chain always wins.
Multi-package inheritance. Build a base package on top of pyrig with shared configs, fixtures, and CLI commands. Every downstream project inherits everything:
pyrig -> service-base -> auth-service
-> payment-service
-> notification-service
All three services get the same standards, hooks, and CI/CD — defined once in service-base.
Everything is adjustable. Every tool and config can be customized or replaced through subclassing. Tools like ruff, ty, and pytest are wrapped in Tool classes — subclass one and pyrig uses yours instead. Want black instead of ruff? Subclass it. Config files work the same way. Standard Python inheritance, no patching.
Source: https://github.com/Winipedia/pyrig
Docs: https://winipedia.github.io/pyrig/
PyPI: https://pypi.org/project/pyrig/