Skip to main content

System checks for your project's environment.

Project description

https://img.shields.io/github/actions/workflow/status/adamchainz/django-version-checks/main.yml.svg?branch=main&style=for-the-badge https://img.shields.io/badge/Coverage-100%25-success?style=for-the-badge https://img.shields.io/pypi/v/django-version-checks.svg?style=for-the-badge https://img.shields.io/badge/code%20style-black-000000.svg?style=for-the-badge pre-commit

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! 🎉

Project details


Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

django_version_checks-1.16.0.tar.gz (10.3 kB view details)

Uploaded Source

Built Distribution

If you're not sure about the file name format, learn more about wheel file names.

django_version_checks-1.16.0-py3-none-any.whl (7.7 kB view details)

Uploaded Python 3

File details

Details for the file django_version_checks-1.16.0.tar.gz.

File metadata

  • Download URL: django_version_checks-1.16.0.tar.gz
  • Upload date:
  • Size: 10.3 kB
  • Tags: Source
  • Uploaded using Trusted Publishing? Yes
  • Uploaded via: twine/6.1.0 CPython/3.13.7

File hashes

Hashes for django_version_checks-1.16.0.tar.gz
Algorithm Hash digest
SHA256 b6ee210378b8cb86aa6366d87850b2dc54fa9a3853fbc477ba47192dc3fe7fe1
MD5 c5800d54e98bd881e92669017f8bec8d
BLAKE2b-256 6aedf7265756174ad079c08a7214ae86122f9161d19cab0338c8fb6f4aafed7b

See more details on using hashes here.

Provenance

The following attestation bundles were made for django_version_checks-1.16.0.tar.gz:

Publisher: main.yml on adamchainz/django-version-checks

Attestations: Values shown here reflect the state when the release was signed and may no longer be current.

File details

Details for the file django_version_checks-1.16.0-py3-none-any.whl.

File metadata

File hashes

Hashes for django_version_checks-1.16.0-py3-none-any.whl
Algorithm Hash digest
SHA256 814f58e98410dd15a1665bb8ecaf4fcfee018f5eedbfd53b6a1f27dbe30b87e4
MD5 f910eb5749005c38edf84c94b5cbd51f
BLAKE2b-256 fe63b3302aeff5a889fd3b1b876d7bc6310f86669fb8f2585acfd2e069fa499a

See more details on using hashes here.

Provenance

The following attestation bundles were made for django_version_checks-1.16.0-py3-none-any.whl:

Publisher: main.yml on adamchainz/django-version-checks

Attestations: Values shown here reflect the state when the release was signed and may no longer be current.

Supported by

AWS Cloud computing and Security Sponsor Datadog Monitoring Depot Continuous Integration Fastly CDN Google Download Analytics Pingdom Monitoring Sentry Error logging StatusPage Status page