-
Notifications
You must be signed in to change notification settings - Fork 5
WIP: chore(deps): Upgrade to Django 5.2 #177
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?
Conversation
…i migrations for django 5
|
Minimum allowed coverage is Generated by 🐒 cobertura-action against e0b02f7 |
| else | ||
| echo "No unapplied migrations." | ||
| fi | ||
| python manage.py migrate --fake-initial --noinput |
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.
Why were we able to simplify so much? This seems much less brittle which is great, but are we looking at any side effects? We were conditionally doing this before so was that just not required?
| import logging | ||
|
|
||
| from asgiref.sync import sync_to_async | ||
| from channels.db import database_sync_to_async |
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.
if my understanding is correct this is basically like some additional ORM aware niceties that channels takes advantage of. this seems like a very good change.
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.
I get the idea and I'm not opposed to dropping versioning, but on the other hand it seems like it's generally been better for us than just taking anything. Maybe we can find a middle ground and just do major version pinning? This goes for all the requirements files.
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.
Nice this would close (or at least go a long way towards closing) #168
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.
I can't see why this is bad, but does it suggest we don't need to use WhoFilter anymore? I think I liked testing WhoFilter directly instead of testing the same thing in a different way. I do think we want to keep it since it's what is used on the admin panel to allow you to filter the list based on the user who added the entry. Maybe I'm overthinking it.
| self.superuser = get_user_model().objects.create_superuser("admin", "admin@es.net", "admintestpassword") | ||
| self.client.login(username="admin", password="admintestpassword") | ||
|
|
||
| # Create the ActionType |
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.
The block actiontype is created by default in one of the early migrations. We can depend on it existing, but maybe this is a case of "better to be explicit"
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.
I'm not sure we want this change, but I need to better understand the usage here. password1 and password2 to me suggests a whole password management solution that I don't think we use.
Well, since it's 2025, I decided to spend down a small nation's amount of energy on Vibe Coding® an upgrade to django 5.2 and python 3.13.
It made a ton of changes I don't understand, but it's less than I figured. And FWIW, the same approaches came about by gemini, claude, and GPT 5o.
I hate this, but the tests do pass locally, so I figured i'd throw this up here for discussion.