The initial scaffolding PR (#2) included a templates/ directory (SECURITY.md, CONTRIBUTING.md, AGENTS.md, dependabot configs, pre-commit config) and a python/pyproject-snippets.toml (ruff/pyright/codespell/coverage config), all intended to be copied into our repos. We pulled them out of that PR because how we deliver these is a real design decision worth its own discussion.
The standardised decisions behind the Python tooling config now live in python/STYLE.md; this issue is about the delivery mechanism for the actual ready-to-copy files (both the repo templates and the pyproject.toml config).
The dominant use case is avoiding drift across our existing repos (operator, jubilant, pytest-jubilant, charmhub-listing-review, charmlibs, …) rather than bootstrapping new repos, which we don't do often.
Options to weigh:
- GitHub template repository ("Use this template") — good for new repos, but one-shot and no ongoing sync.
- cookiecutter — parameterised generation (handles
{{REPO}}-style placeholders), but also one-shot; no update path for existing repos.
- copier — templating with update support, so existing repos can pull in later changes. Best fit for the drift use case, at the cost of an extra tool/dependency.
- Documented copy-from-source — what the PR did; simplest, but drift-prone and manual.
Decide on the approach and, if it's a separate repo/tool, set it up and migrate the template files and the Python tooling config there.
The initial scaffolding PR (#2) included a
templates/directory (SECURITY.md, CONTRIBUTING.md, AGENTS.md, dependabot configs, pre-commit config) and apython/pyproject-snippets.toml(ruff/pyright/codespell/coverage config), all intended to be copied into our repos. We pulled them out of that PR because how we deliver these is a real design decision worth its own discussion.The standardised decisions behind the Python tooling config now live in
python/STYLE.md; this issue is about the delivery mechanism for the actual ready-to-copy files (both the repo templates and thepyproject.tomlconfig).The dominant use case is avoiding drift across our existing repos (operator, jubilant, pytest-jubilant, charmhub-listing-review, charmlibs, …) rather than bootstrapping new repos, which we don't do often.
Options to weigh:
{{REPO}}-style placeholders), but also one-shot; no update path for existing repos.Decide on the approach and, if it's a separate repo/tool, set it up and migrate the template files and the Python tooling config there.