System checks for your project’s environment.
Improve your Django and Git skills with my books.
Requirements
Python 3.9 to 3.14 supported.
Django 4.2 to 6.0 supported.
Installation
First, install with pip:
python -m pip install django-version-checks
Second, add the app to your INSTALLED_APPS setting:
INSTALLED_APPS = [
...,
"django_version_checks",
...,
]
Third, add a VERSION_CHECKS setting with the version checks you want to enforce (as documented below). For example:
VERSION_CHECKS = {
"python": "==3.9.*",
}
Usage
See also the introductory blog post.
django-version-checks adds several system checks that can help ensure that the current environment has the right versions of Python, databases, etc. This is useful when coordinating upgrades across all your infrastructure.
Note that django-version-checks does not check the versions of your Python dependencies. This is because mismatched dependency versions are likely to cause ImportErrors or other import-time problems, before system checks run. To version check your Python dependencies, try pip-lock.
Checks use the PEP 440 specifier format via the packaging module. This is the same format used by pip, and allows some flexibility in specifying valid version ranges. The ~= operator is particularly useful. For example, you can use ~=3.9.1 to mean “3.9.1+, but less than 3.10.0”, allowing environments to take on patch releases without changes, but nothing more.
The individual checks are documented below. Each occupies a key in the VERSION_CHECKS dictionary, and documents its supported types for specifiers. If a check is misconfigured with a bad type or specifier you will see one of these system check errors:
dvc.E001: <check> is misconfigured. Expected a <type> but got <value>.
dvc.E002: <check> is misconfigured. <value> is not a valid PEP440 specifier.
mysql check
This check compares the current version of MariaDB/MySQL to the given specifier. The range can specified either as a single string:
VERSION_CHECKS = {
"mysql": "~=10.5.8",
}
…or as a dictionary mapping database aliases to their specifiers:
VERSION_CHECKS = {
"postgresql": {
"default": "~=10.5.8",
"analytics": "~=10.4.17",
},
}
Note: as a database check, Django will only run this during migrate or when using check --database (Django 3.1+) / check --tags database (Django <3.1). See (docs).
If this check fails, the system check will report:
dvc.E005: The current version of MariaDB/MySQL (<version>) for the <alias> database connection does not match the specified range (<range>).
postgresql check
This check compares the current version of PostgreSQL to the given specifier. The range can specified either as a single string:
VERSION_CHECKS = {
"postgresql": "~=12.2",
}
…or as a dictionary mapping database aliases to their specifiers:
VERSION_CHECKS = {
"postgresql": {
"default": "~=12.2",
"analytics": "~=13.1",
},
}
Note: as a database check, Django will only run this during migrate or when using check --database (Django 3.1+) / check --tags database (Django <3.1). See (docs).
If this check fails, the system check will report:
dvc.E004: The current version of PostgreSQL (<version>) for the <alias> database connection does not match the specified range (<range>).
python check
This check compares the current version of Python to the given single specifier:
VERSION_CHECKS = {
"python": "~=3.9.1",
}
If this check fails, the system check will report:
dvc.E003: The current version of Python (<version>) does not match the specified range (<range>).
sqlite check
This check compares the current version of SQLite to the given single specifier:
VERSION_CHECKS = {
"sqlite": "~=3.37",
}
Note: as a database check, Django will only run this during migrate or when using check --database (Django 3.1+) / check --tags database (Django <3.1). See (docs).
If this check fails, the system check will report:
dvc.E006: The current version of SQLite (<version>) does not match the specified range (<range>).
Example Upgrade
Let’s walk through using django-version-checks to upgrade Python from version 3.8 to 3.9. We have an infrastructure consisting of CI, staging, and production environments, and several developers’ development machines.
First, we add a pre-existing check to ensure that all environments are on Python 3.8:
VERSION_CHECKS = {
"python": "~=3.8.6",
}
Second, we rewrite the specifier to allow versions of Python 3.9:
VERSION_CHECKS = {
"python": ">=3.8.6,<3.10.0",
}
Third, we upgrade our infrastructure. We’d probably upgrade in the order: CI, development environments, staging, production. Each environment should have an automated run of manage.py check, as per the Django deployment checklist.
Fourth, we change the specifier again to allow Python 3.9 only:
VERSION_CHECKS = {
"python": "~=3.9.1",
}
And we’re upgraded! 🎉
Metadata
Release files for django-version-checks 1.16.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| django_version_checks-1.16.0.tar.gz | 10.3 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| django_version_checks-1.16.0-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 18.0 kB
Release files / django_version_checks-1.16.0.tar.gz
| Download URL | django_version_checks-1.16.0.tar.gz |
|---|---|
| Size | 10.3 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
b6ee210378b8cb86aa6366d87850b2dc54fa9a3853fbc477ba47192dc3fe7fe1
|
|
BLAKE2b-256 checksum How to use checksums |
6aedf7265756174ad079c08a7214ae86122f9161d19cab0338c8fb6f4aafed7b
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.7
|
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 Sep 18, 2025.
Transparency logRelease files / django_version_checks-1.16.0-py3-none-any.whl
| Download URL | django_version_checks-1.16.0-py3-none-any.whl |
|---|---|
| Size | 7.7 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
814f58e98410dd15a1665bb8ecaf4fcfee018f5eedbfd53b6a1f27dbe30b87e4
|
|
BLAKE2b-256 checksum How to use checksums |
fe63b3302aeff5a889fd3b1b876d7bc6310f86669fb8f2585acfd2e069fa499a
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.7
|
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 Sep 18, 2025.
Transparency log