[Update Django] Django 5.1

[github-actions]

5.1 requirements tables

base.txt

Name	Version in Master	5.1 Compatible Version	OK
python-slugify	8.0.4	n/a	✅
Pillow	11.0.0	n/a	✅
rcssmin	1.1.2	n/a	✅
argon2-cffi	23.1.0	n/a	✅
whitenoise	6.7.0	6.7.0	✅
redis	5.1.1	n/a	✅
hiredis	3.0.0	n/a	✅
celery	5.4.0	n/a	✅
django-celery-beat	2.7.0	2.7.0	✅
flower	2.0.1	n/a	✅
uvicorn	0.32.0	n/a	✅
uvicorn-worker	0.2.0	n/a	✅
django	5.0.9	2.7.0	✅
django-environ	0.11.2		❓
django-model-utils	5.0.0	5.0.0	✅
django-allauth	65.0.2	64.1.0	✅
django-crispy-forms	2.3	2.3	✅
crispy-bootstrap5	2024.10	2024.10	✅
django-compressor	4.5.1	4.5.1	✅
django-redis	5.4.0		❌
djangorestframework	3.15.2		❌
django-cors-headers	4.5.0	4.4.0	✅
drf-spectacular	0.27.2		❌
django-webpack-loader	3.1.1	3.1.1	✅

local.txt

Name	Version in Master	5.1 Compatible Version	OK
watchdog	4.0.2	n/a	✅
Werkzeug	3.0.4	n/a	✅
ipdb	0.13.13	n/a	✅
psycopg	3.2.3	n/a	✅
watchfiles	0.24.0	n/a	✅
mypy	1.11.2	n/a	✅
django-stubs	5.1.0		❌
pytest	8.3.3	n/a	✅
pytest-sugar	1.0.0	n/a	✅
djangorestframework-stubs	3.15.1	n/a	✅
sphinx	8.1.3	n/a	✅
sphinx-autobuild	2024.10.3	n/a	✅
ruff	0.7.0	n/a	✅
coverage	7.6.3	n/a	✅
djlint	1.35.2	n/a	✅
pre-commit	4.0.1	n/a	✅
factory-boy	3.3.1	3.3.1	✅
django-debug-toolbar	4.4.6		❌
django-extensions	3.2.3		❌
django-coverage-plugin	3.1.0		❌
pytest-django	4.9.0	4.9.0	✅

production.txt

Name	Version in Master	5.1 Compatible Version	OK
gunicorn	23.0.0	n/a	✅
psycopg	3.2.3	n/a	✅
Collectfasta	3.2.0	n/a	✅
sentry-sdk	2.17.0	n/a	✅
hiredis	3.0.0	n/a	✅
django-storages	1.14.4		❌
django-anymail	12.0	12.0	✅

[foarsitter]

django-storages 1.14.4 should be good according to jschneier/django-storages#1444

[foarsitter]

@browniebroke you did some upstream work on DRF on this topic. Is it compatible with Django 5.1 or do we need to await a release?

[browniebroke]

I did add it to the CI and everything passes without any changes. At work, we've got our main project running Django 5.1 and DRF 3.15 and didn't notice any issues.

The only known incompatibility is that the current DRF 3.15 doesn't support LoginRequiredMiddleware. It's fixed in the DRF master branch but currently unreleased.

[joelpelaez]

@browniebroke I found an issue while running CI from Django 5.0.9 to 5.1.2.

If a project is generated with option username_type to username, the test TestUserAdmin.test_add fails with an error like this:

django.core.exceptions.FieldError: Unknown field(s) (usable_password) specified for User. Check fields/fieldsets/exclude attributes of class UserAdmin.

This is caused by multiples changes in Django 5.1:

django/django#16942
django/django#18484

This change introduces a new field named usable_password, and it can cause conflicts with customized UserAdminCreationForm

The new default value of UserAdmin.add_fieldsets is this:

django/django/blob/263f7319192b217c4e3b1eea0ea7809836392bbc/django/contrib/auth/admin.py

When username_type is username the custom UserAdmin doesn't change the field value, only if email type is selected:

cookiecutter-django/{{cookiecutter.project_slug}}/{{cookiecutter.project_slug}}/users/admin.py

Lines 46 to 57 in 931e300

	{%- if cookiecutter.username_type == "email" %}
	ordering = ["id"]
	add_fieldsets = (
	(
	None,
	{
	"classes": ("wide",),
	"fields": ("email", "password1", "password2"),
	},
	),
	)
	{%- endif %}

In Django documentation gives a possible solution: replace UserCreationForm by AdminUserCreationForm, but it was included in Django 5.1.1 and it requires update Django dependency version from series 5.0 to 5.1.

[browniebroke]

Yes we may have to adapt a few things, and thanks for sharing that, will be useful when we get to it.