In 5a8c33f34a the minimum version was set to 7.3 to allow use of the long-form `--fail-on-warning` option, but this is not compatible with Python 3.8. Revert this to the original `-W` option and set 7.0 as the minimum version.
We only support Django 4.2 and 5.0. DRF v3.14.0 was released on
22-09-2022, while Django 4.2 was released on 03-04-2023. This means
Django 4.2 and 5.0 support were officially introduced in DRF 3.15.0.
While our tests used to indicate our use of an older version of DRF
didn't cause any issues when installed with a newer version of Django,
we should bump this anyway. This prevents people from installing a
cached version of DRF that we "claim" to be compatible with Wagtail,
but in reality DRF itself doesn't officially support our minimum Django
version. In such cases, the installation can still proceed as DRF does
not impose an upper bound on Django.
This also fixes an issue where our tests would fail when installed with
DRF < 3.15.0 as the PermissionDenied error messages became more
specific.
This ensures that people upgrading to Django 5.0 will have a compatible version. Now that Python <3.8 and Django <3.2 are EOL, there's no reason for anyone to be running an older version.
This allows the more "adventurous" to update their requirements so they
can install the next latest Django version (5.1 and 5.2) even if we
haven't officially supported it. As long as we're on top of Django's
updates, this should be OK for the duration of this Wagtail release's
active support period.
However, do not update the default project template's requirements yet,
since we don't want new projects to be installed with Django versions we
haven't officially supported.
Notably, this changes the behaviour of multi-line HTML tags so that attributes are aligned (https://github.com/rtts/djhtml#new-multi-line-html-elements). The pre-commit hook was already set to use djhtml 3.0.6, which meant that it was making changes that conflicted with the formatting rules enforced by the Makefile and CI.
Relax the upper version bound to <2, because we're unlikely to stay on top of keeping the version listed in testing_extras up to date, and if boto makes breaking changes that violate semver, that's going to affect end-users so we really want to know about it sooner rather than later.
These tests seem to have been written with the intent of testing query construction independently of actually running the queries; to do this, they mock the relevant bits of elasticsearch-py so that no actual server needs to be running. However, this is a bit of a bodge job - it still instantiates the Elasticsearch object when initialising the backend, so *some* version of elasticsearch-py must be installed to run Wagtail's test suite; and furthermore, that installed version must be able to handle EVERY backend's variant of the `Elasticsearch(...)` constructor, regardless of whether it was written for a completely different version.
This breaks down with Elasticsearch 8, which makes backward-incompatible changes to the constructor. Since the CI suite as a whole will test each backend with its corresponding correct version of elasticsearch-py at some point, it's redundant (and a waste of CPU cycles) to repeat those tests in environments with a different ES version (or none at all).
Matt Westcott