✨ DipDup 7.0 is out! Visit⠀Release Notes⠀page for details⠀✨

DipDup contribution guide

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.


  • All code in this repository MUST be licensed under the MIT License.
  • Python code in this repository MUST run on Python 3.10. It also SHOULD run on Python 3.11. Using modern language features is encouraged.
  • Python code in this repository MUST run in Linux, macOS, Docker, and amd64/arm64 environments. Windows SHOULD be supported as well.
  • We use the Poetry package manager and GNU Make to set up the development environment. You SHOULD install both tools and run make help to see available shortcuts.
  • Developers SHOULD have fun while contributing to the project.


  • Branch names MUST follow prefix/short-description format. Prefixes currently in use: feat for features, fix for bugfixes, docs for documentation, exp for experiments, aux for everything else.
  • Commits in pull requests MUST be squashed when merging to master.
  • Issues and pull requests MUST have a descriptive title; they SHOULD be linked to each other, appropriately labeled, and assigned to maintainers while in progress.


  • We use the following combo of linters and formatters: isort, black, ruff, mypy. All linter checks MUST pass before merging code to master (CI will fail otherwise).
  • Single quotes MUST be used for string literals.
  • Meaningful comments are highly RECOMMENDED to begin with # NOTE:, # TODO:, or # FIXME:.
  • f-string formatting is RECOMMENDED over other methods. Logging is an exception to this rule.


  • All dependencies MUST be declared in pyproject.toml file.
  • Non-development dependencies MUST be pinned to non-breaking versions (e.g. ^1.2.3).
  • Core dependencies that we patch MUST be pinned to specific versions (e.g. 1.2.3).


  • Release versions MUST conform to Semantic Versioning. Releases that introduce breaking changes MUST be major ones.
  • Only the latest major version is supported in general. Critical fixes MAY be backported to the previous major release. To do so, create an aux/X.Y.Z branch from the latest stable tag, bump the DipDup version manually, and add a new tag.


  • All changes that affect user (developer) experience MUST be documented in the CHANGELOG.md file.
  • Changes that significantly affect DipDup maintainers' experience MAY be documented in the CHANGELOG.md file.
  • The changelog MUST conform to the "Keep a Changelog" specification (CI will break otherwise).
  • Lines describing changes MUST be sorted and begin with DipDup module name (index: Added ...).


  • A page in Release Notes SHOULD accompany all major releases.
  • All internal links MUST be created with {{ #summary ... shortcodes.
  • All values used in project templates MUST be replaced with {{ #cookiecutter ... shortcodes.


  • GitHub alerts about dependencies that contain vulnerabilities MUST be investigated and resolved as soon as possible.
  • Security-related bugfixes MUST be mentioned in the changelog under the "Security" section.


  • Crash reporting MUST be opt-in (disabled by default) both in config and project templates.
  • Sentry events and crash reports MUST NOT contain any sensitive information (IP addresses, hostnames, etc.)
  • DipDup SHOULD NOT perform network requests to APIs not defined in config as datasources. Current exceptions: GitHub.

Docker images

  • DipDup dockerfiles use autogenerated requirements.txt files. Maintainers MUST run make update script on every change in dependencies.
  • Docker images for stable releases MUST be published on Docker Hub. They MAY also be published on GHCR.
  • Maintainers MAY publish arbitrary images on GHCR and remove them when not needed.


  • Installer module MUST depend on Python stdlib only.


  • Project templates SHOULD cover all index types available in DipDup.
  • They also MAY contain additional features and integrations.

Demo projects

  • Demos are stored in demos root directory. They MUST be generated automatically from project templates using replay files.
  • Maintainers SHOULD run make demos replays command regularly to ensure that demo projects are up to date.
This page or paragraph is yet to be written. Come back later.


Code Review