-
Notifications
You must be signed in to change notification settings - Fork 466
deps: update to django5 #6452
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
base: main
Are you sure you want to change the base?
deps: update to django5 #6452
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. 3 Skipped Deployments
|
074f8f9 to
f466b13
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #6452 +/- ##
==========================================
+ Coverage 98.06% 98.08% +0.01%
==========================================
Files 1292 1295 +3
Lines 46509 46515 +6
==========================================
+ Hits 45611 45622 +11
+ Misses 898 893 -5 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
4daf736 to
bafcaff
Compare
matthewelwell
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor comments for context where needed.
|
|
||
| ENABLE_POSTPONE_DECORATOR = False | ||
|
|
||
| DEBUG = True |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After the upgrade of django-debug-toolbar, this was causing issues because we only include the debug toolbar if DEBUG is True (see here). As I understand it, it's because we don't also add it to installed_apps here which is now required (but seemingly wasn't in older versions of the package).
I decided the better solution here was simply to remove the DEBUG = True as I'm not sure why it existed here for tests in the first place.
| migrations.RenameIndex( | ||
| model_name="apiusageraw", | ||
| new_name="app_analyti_environ_b61cad_idx", | ||
| old_fields=("environment_id", "created_at"), | ||
| ), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Caused by deprecation of Model.Meta.index_together. I've researched and, as I understand it, it requires a lock on the metadata, but no the table or index itself.
Since we don't reference the name of the index directly (although we might in specific oracle migrations 🤔) we shouldn't have any schema mismatch issues.
| if serialized_codes is None: # pragma: no cover | ||
| return |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added for typing reasons.
| feature=feature_health_event.feature, | ||
| environment=feature_health_event.environment, | ||
| type=FeatureHealthEventType.HEALTHY, | ||
| type=FeatureHealthEventType.HEALTHY.value, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This one was somewhat odd. I can't see any indication of any changes to this behaviour in the notes here, but looking at this test I do think it was wrong previously anyway.
The error that I was seeing was that it couldn't create the event with the type as the literal string "FeatureHealthEventType.HEALTHY" which makes sense - perhaps Django 5 is more strict on enforcing the choices behaviour. Either way, I think this change is a good step.
| # Note: This migration is a no-op, and just adds the `through_fields` attribute | ||
| # seemingly needed by the state in django5 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This migration is a no-op as per this comment.
| length: int = 10, | ||
| allowed_chars: str = string.ascii_letters + string.digits, | ||
| ) -> str: | ||
| return "".join(secrets.choice(allowed_chars) for _ in range(length)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
make_random_password was removed. I simply re-added it, using the guidance provided here.
| djangorestframework-dataclasses = "^1.3.1" | ||
| pyotp = "^2.9.0" | ||
| flagsmith-common = "^2.2.7" | ||
| flagsmith-common = { git = "https://github.com/flagsmith/flagsmith-common", branch = "deps/django-5-upgrade" } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TODO: replace this with the new version once released.
Docker builds report
|
Changes
Note: depends on Flagsmith/flagsmith-common#149
Upgrade to django 5.
There were seemingly very few changes that were needed, and most of the updates in this PR relate to typing updates which I've tried to fix where possible but erred on the side of
type: ignorecomments where needed.The main breaking changes that required handling on our end were:
Model.Meta.index_togetherwas removed. I've replaced usages of this withmodels.Index(fields=[...]). This change does result in a migration applied to the database in the form of aRenameIndexbut from what I can tell, this is a very minor operation and doesn't require any locks on the data in the table, or the index, only on the metadata for the table.django.utils.timezone.utcwas removed. I've replaced this withdatetime.timezone.utc, but since we still want to usedjango.utils.timezonefor other logic, (e.g.timezone.now()), I've importeddatetime.timezoneasdttzwhere needed.I also had to update a few dependencies to support the django upgrade:
Note that the upgrade of django-debug-toolbar meant that I needed to remove
DEBUG = Truefrom the test settings (conversation on the actual LoC for clarification).How did you test this code?
Unit tests, and running locally.