🐛 Settings are loaded eagerly instead of lazily

[sergei-maertens]

Bug Description

The settings of django-health-check (from health_check.conf) are loaded at import time rather than dynamically accessing them when they're needed trough a callable or other defer mechanism.

This is mostly annoying for testing in projects/downstream libraries. Our package provides opt-in support and allows configuring the necessary settings in the test module with a construct like:

@pytest.fixture(autouse=True)
def _add_installed_apps(settings):
    settings.INSTALLED_APPS = [
        *settings.INSTALLED_APPS,
        *default_health_check_apps,
    ]
    settings.HEALTH_CHECK = {
        "SUBSETS": default_health_check_subsets,
    }

The updated HEALTH_CHECK setting is not picked up here because the view was already imported before this code runs, which had trigger the import of the conf module which evaluated the django settings at import time.

A common pattern we apply is:

from typing import Literal

from django.conf import settings

HEALTH_CHECK = {}

type SettingName = Literal["HEALTH_CHECK"]


def get_setting(name: SettingName):
    default = globals()[name]
    return getattr(settings, name, default)

would you be open to a patch in this direction?

Expected Behavior

django-health-check plays nice with the pytest-django settings fixture and the @override_settings decorator from django.test.

Version

3.20.8

Stack trace

When applying the pattern described above in a test, this results in a 404 because the subset "does not exist":

    def test_readyz_subset_endpoint(client: Client):
        response = client.get("/_healthz/readyz/")
    
        # there are pending migrations because of the added health check installed apps,
        # which results in HTTP 500 response (as intended).
>       assert response.status_code in (200, 500)
E       assert 404 in (200, 500)
E        +  where 404 = <HttpResponseNotFound status_code=404, "text/html; charset=utf-8">.status_code

tests/health_checks/test_endpoints.py:53: AssertionError

Steps to Reproduce

No response

[sergei-maertens]

This may also be an opportunity to address #459 and build in the deprecation warning for the old setting name while remaining backwards compatible :)

[codingjoe]

Hi there 👋,

Thanks for bringing this up. The settings have been an issue for a long time.
You will be pleased to hear that all settings are gone now ;)

For more information see: https://codingjoe.dev/django-health-check/migrate-to-v4/

Cheers!
Joe

Resolved in #551

[sergei-maertens]

@codingjoe do you have a planned release date for v4? Purely so that I can allocate time in my calendar for the upgrade :)

edit: also I see the docs have been updated for v4 already, but the v3 docs don't seem to be available any longer, while v3 is still the latest version on PyPI

[codingjoe]

Hi @sergei-maertens,

sorry for the confusing documentation. v3.21 already includes the new API as well as the old one. So you can update now or keep waiting for v4. However, the latter will remove old APIs and require you to do the code changes.

This was meant to give everyone more time to react to the breaking changes.

However, I will ship another 3.x version today with one more depreciation. So, maybe wait until tomorrow 🫣 at least if you have any custom checks or use redis.

Cheers,
Joe

[sergei-maertens]

Sweet - doesn't sound like the additional depreciations affect us, so I'll get started on 3.21!

[codingjoe]

Thanks @sergei-maertens for mentioning this. I added a clarification to the documentation: https://codingjoe.dev/django-health-check/migrate-to-v4/ (you might need to hard reload)

v4 comes packed with exciting new checks and integration features and a long long overdue cleanup. I will probably releaes it this week :)