Skip to main content

opentemplate

All-in-one Python template. One click. Everything included.

✨ Features 🚀 Quick start 📚 Documentation 🤝 Contribute 👍 Adopters 📜 Legal


Features

opentemplate is a Python template which is:

[!IMPORTANT] An example repository using opentemplate here

[!CAUTION] All files in this repo will be copied to your project, using the title and description you provide.

Code quality (Python focused)

[!IMPORTANT] You can adjust everything from pyproject.toml level!

  • Package manager: pdm with a single pdm setup manages everything! (see why pdm)
  • Testing: pytest (with coverage, and hypothesis for fuzzing); testing across all Python versions done WITHOUT tox or nox(managed directly by pdm!)
  • Documentation: mkdocs - document once, have it everywhere (unified look on GitHub and hosted docs), semantically versioned (via mike), autogenerated from coverage, deadlink and spell-checked docstrings, automatically deployed after each GitHub release with clean material design look
  • Code formatting and linting: ruff (checks hand-picked for best quality and ease of use; most are enabled), basedpyright for type checking, FawltyDeps for static dependency analysis
  • Each file is copyrighted with your git information - copyrights added automatically by pre-commit, see REUSE and SPDX Licensing for more information
  • Automated Python version updates: pyproject.toml (and GitHub Actions pipelines where necessary) are automatically updated to always use 3 latest Python versions (via cogeol) according to Scientific Python SPEC0 deprecation and end-of-life policies
  • Other code linting: checks for YAML, Markdown, INI, JSON, prose, all config files, shell, GitHub Actions - all grouped as check-<group> and fix-<group> pdm commands
  • Release to PyPI and GitHub: done by making a GitHub release, each release is attested and immutably versioned via commition
  • pre-commit: all checks and fixers are run before commit, no need to remember them! (pre-commit is also setup after running a single pdm setup command!)

Security

[!IMPORTANT] Everything below is already provided out of the box, one-click only!

  • Hardening: during setup, an automated issue is created to guide you step by step through enabling rulesets, branch protection, mandatory reviewers, necessary signatures etc. (see here for an example). Best part? harden.yml workflow, which does that automatically (if you follow the instructions in the issue)!
  • SLSA compliance: Level 3+ for public/enterprise repositories and L2 for private repositories via slsa-github-generator
  • Software Bills of Materials (SBOMs): generated per-Python, per-OS, per-dependency group - each attested, and attached to the release
  • Static security analysis tooling: osv-scanner checks against OSV database, semgrep monitors code quality and security, zizmor verifies workflows, while trufflehog looks for leaked secrets
  • Reusable workflows: most of the workflows are reusable (pointing to opentemplate workflows) to improve security and get automated pipeline updates - you can make them local by running .github/reusability/localize.sh script. No need to manage/update your own workflows!
  • Pinned dependencies: all dependencies are pinned to specific versions (GitHub Actions, pre-commit and pdm.lock)
  • Monitored egress in GitHub Actions: harden-runner with a whitelisted minimal set of domains necessary to run the workflows
  • Security documentation: SECURITY.md, SECURITY-INSIGHTS.yml, SECURITY-SELF-ASSESSMENT.md (only security file to update manually before release), and SECURITY-DEPENDENCY.md define high quality security policies

[!TIP] See this example release for all security artifacts described above.

[!NOTE] Although there is around 100 workflows helping you maintain high quality, most of them reuse the same workflow, which makes them maintainable and extendable.

GitHub

  • GitHub Actions cache - after each merge to the main branch, dependencies are cached per-group and per-OS for maximum performance
  • Minimal checkouts and triggers - each workflow is triggered based on appropriate path and performs sparse-checkout when possible to minimize the amount of data transferred; great for large repositories with many files and large history
  • Dependency updates: Renovate updates all dependencies in a grouped manner once a week
  • Templates: every possible template included (discussions, issues, pull requests - each extensively described)
  • Predefined labels - each pull request will be automatically labeled (over 20 labels created during setup!) based on changed files (e.g. docs, tests, deps, config etc.). No need to specify semver scope of commit anymore!
  • Open source documents: CODE_OF_CONDUCT.md, CONTRIBUTING.md, ROADMAP.md, CHANGELOG.md, CODEOWNERS, DCO, and much more - all automatically added and linked to your Python documentation out of the box
  • Release changelog: git-cliff - commits automatically divided based on labels, types, human/bot authors, and linked to appropriate issues and pull requests
  • Config files: editorconfig, .gitattributes, always the latest Python .gitignore etc.
  • Commit checks: verification of signatures, commit messages, DCO signing, no commit to the main branch policy (via conform)

Comparison

  • Broader scope than other cookiecutter templates (e.g. one-click and one-command setup, security, GitHub Actions, comprehensive docs, rulesets. deprecation policies, automated copyrights and more). Check here or here to compare yourself.
  • Truly FOSS (no freemium, no paid plans, no tokens) when compared to commercial offerings like snyk or jit.io. Additionally Python-centric and sticks with tools widely known by developers (their own environment and GitHub interface).

[!TIP] See detailed comparison in the documentation

Quick start

Installation

[!NOTE] Install pdm (if you don't have it already), for Linux/MacOS:

curl -sSL https://pdm-project.org/install-pdm.py | python3 -
  1. Create a new GitHub repository using this template (green Use this template button)
  2. Name your repo (use underscore _, not hyphens -)
  3. Add project description (necessary!)
  4. Wait until the setup commit appears (performed by github-actions[bot], it may take a few minutes)
  5. Clone the repository
  6. Run pdm setup command locally to setup development environment

[!TIP] For more details read the documentation

Usage

  1. Create a new branch
  2. Optionally add dependencies to pyproject.toml
  3. Write code in /src/<project_name> and tests in /tests
  4. Use git add, git commit and git push your changes
  5. pre-commit will guide you through the process

[!TIP] For more details read the documentation

Examples

[!CAUTION] Click on each example to see it in action!

Run checkers or fixers manually (click me)  
> pdm check-<group> [FILE1, FILE2, ...] # pdm fix-<group>

For example, to check all Python files:

> pdm check-python

Or to check /src/__init__.py:

> pdm check-python src/__init__.py

Note that all check and fix commands are grouped for your convenience:

> pdm check-all # pdm fix-all
Adjust template (click me)  

Most of the adjustments can be done by only editing pyproject.toml

Common changes to pyproject.toml:

  • Add dev dependencies under [dependency-groups] (everything is named dev-<group>)
  • Modify [tool.pdm.scripts] for custom command (check-<group> or fix-<group>, the latter modifies files)
  • Use [tool.<name>] to adjust specific tool configuration

Adjusting these sections will affect pre-commit and GitHub Actions

Disable some pre-commit check (click me)  

Disabling checks should be done cautiously!

pre-commit checks are defined in .pre-commit-config.yaml.

Disable a check using SKIP environment variable:

SKIP="<group1>,<group2>" git commit -m <message>

For example, the following will skip DCO and ini checks and Python fixes (which would modify files):

SKIP="dco,ini,fix-python" git commit -m <message>

For details, refer to the id fields in .pre-commit-config.yaml.

Some commands have both <group>-fix and <group>-check for different actions!

Disable GitHub Actions checks (click me)  

Disabling checks should be done cautiously!

When making a commit you can add one of the following strings to the message:

  • [skip ci]
  • [ci skip]
  • [no ci]
  • [skip actions]
  • [actions skip]

Note that you can also merge pull requests even if the checks fail.

Contribute

We welcome your contributions! Start here:

Legal

  • This project is licensed under the Apache 2.0 License - see the LICENSE file for details.
  • This project is copyrighted by open-nudge - the appropriate copyright notice is included in each file.

Metadata

Release files for opentemplate 0.4.3

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for opentemplate 0.4.3
File Size Uploaded
opentemplate-0.4.3.tar.gz 19.4 kB Details

Built distribution (wheel)

Table of built distributions (wheels) for opentemplate 0.4.3
File Interpreter ABI Platform
opentemplate-0.4.3-py3-none-any.whl Python 3 none any Details

Total release size: 27.6 kB

Release files / opentemplate-0.4.3.tar.gz

Download URL opentemplate-0.4.3.tar.gz
Size 19.4 kB
Tags Source
SHA-256 checksum
How to use checksums
6067dc0e8620a83d5825b122c84c02d8d9c2b81375727428eb1c1d6a2e529ebd
BLAKE2b-256 checksum
How to use checksums
584f99b00b76985bc21f3a866105b594df0b6f03b95e21e9b12d62cc6f3a2bd4
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.1.0 CPython/3.12.9

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Jul 13, 2025.

Transparency log

Release files / opentemplate-0.4.3-py3-none-any.whl

Download URL opentemplate-0.4.3-py3-none-any.whl
Size 8.2 kB
Tags Python 3
SHA-256 checksum
How to use checksums
d3976a15445feb89b5f283359cd21628f71d745ca65a4bf837a5dceb64cf06b4
BLAKE2b-256 checksum
How to use checksums
e9ce8fe939d757d8a770b520e1d265e4e123cd0b8b1d4843e71af04e6799f829
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.1.0 CPython/3.12.9

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Jul 13, 2025.

Transparency log

Release history Release notifications | RSS feed

This release

0.4.3 This release

2 release files

0.0.1

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page