Update Django to 3.2, remove or update package constraints#128
Update Django to 3.2, remove or update package constraints#128bradenmacdonald merged 6 commits intomasterfrom
Conversation
|
Thanks for the pull request, @symbolist! I've created OSPR-6082 to keep track of it in JIRA. As a core committer in this repo, you can merge this once the pull request is approved per the core committer reviewer requirements and according to the agreement with your edX Champion. |
|
@symbolist Thank you for your contribution. Would @bradenmacdonald be interested in reviewing? |
|
@natabene @symbolist Sure, I can review - just let me know when it's ready. |
06bb859 to
0da0788
Compare
0da0788 to
18d15d7
Compare
18d15d7 to
a62a33e
Compare
|
I tried running this on the LX CI and there were a few test failures. They did seem unrelated but still investigating them. |
symbolist
left a comment
There was a problem hiding this comment.
@bradenmacdonald This is ready for review (see also comment on ticket).
CC @natabene
| python3-pip \ | ||
| python3-venv | ||
| python3-venv \ | ||
| wget |
There was a problem hiding this comment.
Needed for the make upgrade command.
| upgrade: export CUSTOM_COMPILE_COMMAND=make upgrade | ||
| upgrade: $(COMMON_CONSTRAINTS_TXT) ## update the requirements/*.txt files with the latest packages satisfying requirements/*.in | ||
| sed 's/Django<2.3//g' requirements/common_constraints.txt > requirements/common_constraints.tmp | ||
| mv requirements/common_constraints.tmp requirements/common_constraints.txt |
There was a problem hiding this comment.
Need to remove this line to update to Django 3.2 which is specified in constraints.txt.
| ) for (lookup_url_kwarg, lookup_value_regex) in zip(lookup_url_kwargs, lookup_value_regexes) | ||
| f'(?P<{lookup_prefix}{lookup_url_kwarg}>{lookup_value_regex})' for ( | ||
| lookup_url_kwarg, lookup_value_regex | ||
| ) in zip(lookup_url_kwargs, lookup_value_regexes) |
There was a problem hiding this comment.
There are a few conversions to f-strings because of quality issues raised by pylint version upgrade.
| def get_alternative_name(self, name): | ||
| return default_storage.get_alternative_name(name) | ||
| def get_alternative_name(self, file_root, file_ext): | ||
| return default_storage.get_alternative_name(file_root, file_ext) |
There was a problem hiding this comment.
A parameter was added in Django 3. Though this method does not seem to be in use in this package.
| from django.db import migrations, models | ||
|
|
||
|
|
||
| class Migration(migrations.Migration): |
There was a problem hiding this comment.
Added by upgrade to Django 3.2. The only change seems to be the change in max_length.
| django | ||
| django-cors-headers | ||
| django-environ-2 | ||
| django-environ |
There was a problem hiding this comment.
Switched back to django-environ.
This was earlier changed in #121.
| # Not yet using Django 3.X. Using the 2.X LTS to mirror the LMS. | ||
| django>2.2,<2.3 | ||
|
|
||
| django-cors-headers>=2.2.0,<2.3 |
There was a problem hiding this comment.
Not needed so has been removed.
| django-environ-2==2.1.0 | ||
|
|
||
| django-filter==2.1.0 | ||
| django>3.2,<3.3 |
There was a problem hiding this comment.
There don't seem to be any backwards incompatible changes relevant to this repo:
https://docs.djangoproject.com/en/3.2/releases/3.0/#backwards-incompatible-changes-in-3-0
| # via | ||
| # -c requirements/constraints.txt | ||
| # -r requirements/base.in | ||
| django-environ==0.7.0 |
There was a problem hiding this comment.
This was originally pinned to v.0.4.5
There don't seem to be any backwards incompatible changes between 0.4.5 and 0.7.0: https://github.com/joke2k/django-environ/blob/main/CHANGELOG.rst
| # -r requirements/base.in | ||
| django-environ==0.7.0 | ||
| # via -r requirements/base.in | ||
| django-filter==21.1 |
There was a problem hiding this comment.
Constraint on this has been removed. Though there do not seem to be any backwards incompatible changes since 2.1.0: https://github.com/carltongibson/django-filter/blob/main/CHANGES.rst
|
CC @kdmccormick Just a heads up that this will be coming your way for a deploy. 🙂 |
bradenmacdonald
left a comment
There was a problem hiding this comment.
👍 Looks good to me. Thanks!
I did encounter one issue with make easyserver, but it seems unrelated to this PR: the default docker-compose project name is now blockstore3.8 but docker sometimes interprets it as blockstore3 (ignoring parts after the .) which causes enough consistency errors to stop everything from working. I could only get the server running by using BLOCKSTORE_PROJECT_NAME=blockstore38 make easyserver
- I tested this: some basic read+write tests using frontend-app-library-authoring, also confirmed LX test suite is passing
- I read through the code
- I checked for accessibility issues: n/a
- Includes documentation
|
@ormsbee, @kdmccormick: thought you might like to know that symbolist merged this pull request. |
|
@symbolist 🎉 Your pull request was merged! Please take a moment to answer a two question survey so we can improve your experience in the future. |
Using a period in the docker-compose project name has been observed to cause issues. For example: openedx-unsupported#128 (review) So, normalize all references to 3.8 to 38. This fixes the issue, and still retains the filenaming linked with the python version used.
Using a period in the docker-compose project name has been observed to cause issues. For example: openedx-unsupported#128 (review) So, normalize all references to 3.8 to 38. This fixes the issue, and still retains the filenaming linked with the python version used.
Using a period in the docker-compose project name has been observed to cause issues when using docker-compose 2.0. For example: openedx-unsupported#128 (review) So, normalize all references to 3.8 to 38. This fixes the issue, and still retains the filenaming linked with the python version used.
Using a period in the docker-compose project name has been observed to cause issues when using docker-compose 2.0. For example: openedx-unsupported#128 (review) So, normalize all references to 3.8 to 38. This fixes the issue, and still retains the filenaming linked with the python version used.
Using a period in the docker-compose project name has been observed to cause issues when using docker-compose 2.0. For example: openedx-unsupported#128 (review) So, normalize all references to 3.8 to 38. This fixes the issue, and still retains the filenaming linked with the python version used.
Description
corheadersapp + set up.Ticket
Author Comments, Concerns, and Open Questions
None.
Test Instructions