Hi HN,

I built pyrig after getting tired of manually keeping configuration files in sync across multiple Python projects. Every time I'd start a new project or update tooling standards, I'd spend hours copying and tweaking pyproject.toml, GitHub workflows, pre-commit hooks, etc.

pyrig treats project infrastructure as declarative code. Each config file (pyproject.toml, .pre-commit-config.yaml, GitHub workflows) is a Python class that:

- Generates the file with working defaults - Validates existing files against expected structure - Merges missing values without removing your customizations - Runs idempotently (safe to run multiple times)

The interesting part is the multi-package inheritance. You can create a "base" package that extends pyrig with your own customized standards, then all your projects inherit those configs automatically:

  pyrig → your-base → service1
                    → service2

Commands, test fixtures, and config files are discovered automatically across the entire dependency chain using a runtime dependency graph built from importlib.metadata. What makes it different from other scaffolding projects: Pyrig is a system that is kind of living continiously and supports you during code development. You can basically customize everything and tweak almost all behaviour as you see fit.

Quick start: uv init uv add pyrig uv run pyrig init

This generates a complete project: source structure, tests, CI/CD, docs, pre-commit hooks, containerfile, etc. Run it again later to update configs or add missing files.

I'd love feedback on the architecture and this project generally. What do you think? Is this useful or not? I have used it already with many of my projects and it genuinely made things easier and faster for me.

GitHub: https://github.com/Winipedia/pyrig Docs: https://winipedia.github.io/pyrig