Move the custom sdist command from wagtail/utils/setup.py directly to
setup.py, because we cannot import the wagtail package itself during
the build process without installing it in the build environment.
We no longer publish any NPM package from this repository. There is no
package.json in the "client" directory, and we do not include anything
in the "client" directory in the final package either.
The bdist_egg command is deprecated in favour of wheels. We don't
distribute eggs, so the custom version with the static assets check is
not relevant.
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.