This repository is a project template. Changes should preserve two use cases: working on the template itself and generating a clean downstream project from it.
Install the development and documentation dependencies:
uv sync --extra dev --extra docsInstall pre-commit hooks if you want local checks before each commit:
uv run pre-commit installRun the unit tests:
uv run pytestRun type checks:
uv run tox -e typeRun coverage with the configured threshold:
uv run tox -e coverageAudit dependencies for known vulnerabilities:
uv run tox -e securityRun Ruff fixes and formatting:
uv run tox -e formatterBuild and smoke-test the package artifacts:
uv run tox -e buildPreview the generated changelog:
uv run tox -e changelogPrepare a release — bumps the version, regenerates the changelog, commits, and tags:
uv run tox -e release -- 0.1.0
uv run tox -e release -- 0.1.0 --pushPushing the tag triggers the Release workflow, which builds the
distributions and publishes a GitHub Release.
Build and smoke-test the Docker image:
docker build --pull -t python-template:ci .
docker run --rm python-template:ci uv run python -c "import project_name"Build the documentation exactly as CI does:
uv run tox -e docsManual docs live in docs/ and use MyST Markdown. API docs are generated from
Google-style docstrings in the source package. Keep public modules, classes,
and functions documented when adding or changing APIs.
Use a live documentation preview while editing prose or docstrings:
uv run sphinx-autobuild docs docs/_build/htmlBefore opening a pull request, run the strict build with uv run tox -e docs.
When changing placeholder behavior, update scripts/bootstrap_template.py and
the bootstrap tests together. The script must keep generated repositories
usable with locked dependency installs.
Run the generated-project smoke test for changes that affect packaging, documentation, CI, tox, or bootstrap behavior:
uv run tox -e templateThat test creates a temporary project from the template, bootstraps it, syncs it
with uv --locked, imports the renamed package, runs its example tests, builds
docs, and validates distribution artifacts.
A good pull request should include:
- a clear description of the template behavior being changed
- tests for bootstrap or generated-project behavior when relevant
- documentation updates for user-facing workflow changes
- passing tests, coverage, security audit, type checks, docs build, package build, and Docker build when relevant
CHANGELOG.md is generated from commit messages by git-cliff — do not edit it
by hand. What lands in it is decided by the Conventional Commits prefix on each
commit, so write commit subjects that read as release notes on their own,
especially for changes that affect generated projects, supported Python
versions, dependency management, CI behavior, documentation publishing, or the
public template workflow.
Preview the result before opening a pull request:
uv run tox -e changelogThe prefix-to-section mapping and the full release procedure are documented in
the "Commit, license, and release workflow" section of README.md.