Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Support Django 4.1 #3156

Merged
merged 1 commit into from Sep 10, 2022
Merged

feat: Support Django 4.1 #3156

merged 1 commit into from Sep 10, 2022

Conversation

adamchainz
Copy link
Contributor

Submitting Pull Requests

General

  • Make sure you use semantic commit messages.
    Examples: "fix(google): Fixed foobar bug", "feat(accounts): Added foobar feature".
  • All Python code must formatted using Black, and clean from pep8 and isort issues.
  • JavaScript code should adhere to StandardJS.
  • If your changes are significant, please update ChangeLog.rst.
  • If your change is substantial, feel free to add yourself to AUTHORS.

@coveralls
Copy link

coveralls commented Sep 8, 2022

Coverage Status

Coverage increased (+0.01%) to 91.572% when pulling 798e15f on adamchainz:django_4.1 into 6315e25 on pennersr:master.

Comment on lines +162 to +174
if django.VERSION >= (4, 1):
self.assertFormError(
resp.context["form"],
"password2",
"You must type the same password each time.",
)
else:
self.assertFormError(
resp,
"form",
"password2",
"You must type the same password each time.",
)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This and similar changes are all to deal with the test change to assertFormError(). Without it, the test run records warnings from Django like:

/.../lib/python3.10/site-packages/django/test/testcases.py:279: RemovedInDjango50Warning: Passing response to assertFormError() is deprecated. Use the form object directly: assertFormError(response.context['form'], None, ...)

Using a branch on django.VERSION seems to be the most elegant way to handle the two different calling formats. If you use django-upgrade in the future, when dropping <4.1 support, it can rewrite the code to leave only the "new way of doing thigns" with its versioned blocks fixer.

@@ -5,6 +5,7 @@
SITE_ID = 1
ALLOWED_HOSTS = ("*",)
USE_I18N = False
USE_TZ = True
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This settings change is required to deal with this warning from Django 4.0+:

/.../lib/python3.10/site-packages/django/conf/__init__.py:214: RemovedInDjango50Warning: The default value of USE_TZ will change from False to True in Django 5.0. Set USE_TZ to False in your project settings if you want to keep the current default behavior.
  warnings.warn(

It seems that nothing in the test suite is affected by the change - I can't spot any more warnings and there aren't any errors.

@@ -13,7 +13,7 @@ jobs:
fail-fast: false
matrix:
python-version: ['3.5', '3.6', '3.7', '3.8', '3.9', '3.10']
django-version: ['main', '2.0', '2.1', '2.2', '3.0', '3.1', '3.2', '4.0']
django-version: ['main', '2.0', '2.1', '2.2', '3.0', '3.1', '3.2', '4.0', '4.1']
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried to match changes to github actions to the Django 4.0 commit: f02dcfa

@pennersr pennersr merged commit 060cbcf into pennersr:master Sep 10, 2022
@adamchainz adamchainz deleted the django_4.1 branch September 10, 2022 14:36
@simkimsia simkimsia mentioned this pull request Mar 24, 2023
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants