Fix _pre_setup_ran_eagerly on Django 5.0 and 5.1

[sobolevn]

Closes #1303

Locally I double checked that:

• It now works with 5.0 and 5.1
• False is the correct default, with True I get errors like

ERROR tests/test_unit/test_security/test_token/test_app/test_token_model.py::test_create_token_explicit_expiry - AttributeError: 'PytestDjangoTestCase' object has no attribute 'atomics'
ERROR tests/test_unit/test_security/test_token/test_app/test_token_model.py::test_token_is_expired - AttributeError: 'PytestDjangoTestCase' object has no attribute 'atomics'
ERROR tests/test_unit/test_security/test_token/test_app/test_token_model.py::test_token_revoke - AttributeError: 'PytestDjangoTestCase' object has no attribute 'atomics'
ERROR tests/test_unit/test_security/test_token/test_app/test_token_model.py::test_hash_token_is_stored - AttributeError: 'PytestDjangoTestCase' object has no attribute 'atomics'
ERROR tests/test_unit/test_security/test_token/test_app/test_token_model.py::test_create_token_without_expiry - AttributeError: 'PytestDjangoTestCase' object has no attribute 'atomics'
ERROR tests/test_unit/test_security/test_token/test_app/test_token_model.py::test_create_token - AttributeError: 'PytestDjangoTestCase' object has no attribute 'atomics'

[kingbuzzman]

Im confused, why are we supporting 5.1/5.0? Support was dropped 8+ months ago

[sobolevn]

Because it is a single line change and it makes live of many opensource projects that rely on pytest-django and older Django versions much easier :)

[kingbuzzman]

While I agree with the sentiment, my main concern is that this sets a bad precedent. You now have a line of code living there that will likely be forgotten about until someone stumbles across it three years from now and asks, “Is it safe to remove this yet?”

More broadly, what’s the right lifecycle for a workaround like this? If the maintainer of the upstream package has already deemed the affected version outdated and unsupported, how long should we continue carrying a fix for it on our side? At some point, we risk accumulating compatibility code with no clear criteria for when it should be removed.

@bluetech

[bluetech]

@kingbuzzman You are right, this is just a small courtesy.

For the risk of accumulating code, I modified @sobolevn PR slightly to make it conditional on an explicit django.VERSION check, which we occasionally check for and remove old stuff.

But the bigger thing is that pytest-django didn't really provide a nice way for users who support older Django versions to get a compatible pytest-django version. For that reason, I added in the latest version the django extra. So in the future we could tell users "add the django extra and your dependency resolver will do the right thing". But it can't help with existing pytest-django versions, only for future complainers :)

BTW, Django just changes to annual releases and all releases from now on will be LTS. That will simplify things a bit (no more support "gaps"). https://www.djangoproject.com/weblog/2026/aug/10/annual-release-cycle/