Upgrade Django to v5; related work and cleanups

[anadon]

Django 3.x is out of security releases, so I started upgrading to Django 5. I've also implemented a direnv/Nix Flake to 'just' set up a development environment. Lots of small changes. Unfortunately, had to disable 2FA for the time being. I'd like to keep this as a draft to keep track of developments and collaborate. Currently, I'm facing some troubles with some tests related to Square and the environment that I'm not immediately sure how to fix up.

[anadon]

Sorry for the noise, Github is fighting me on verifying commits and I'm not sure why.

[rechner]

Why have all the migrations been deleted? These are not optional, you can squash them to make a new instance setup go faster but removing migrations before every instance has applied them can break someone's database and leave them stranded with no way to up- or down-grade their versions.

Migrations, including the initial one, form the basis of a Django app's database schema.

[anadon]

I believed otherwise. I'll go in an revert the change.

[rechner]

Why the change to UTC here?

[rechner]

It might be possible to upgrade this library to support DJango 5, but might be wiser to switch to something more actively developed like django-allauth.

[anadon]

I will look into it, and re-add 2FA.

[anadon]

There are a few instances where usage is deprecated and the migration guide said to migrate those. https://docs.djangoproject.com/en/dev/internals/deprecation/ . Namely the guide said to run python with `-Wa` and look for mention of deprecation warnings. Those are what came up.

…

On Sat, Dec 28, 2024 at 7:39 PM Rechner Fox ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In registration/views/staff.py <#339 (comment)>: > @@ -164,12 +166,14 @@ def add_new_staff(request): def staff_index(request, guid): event = Event.objects.get(default=True) tz = timezone.get_current_timezone() - today = tz.localize(datetime.now()) + today = datetime.now(python_tz.utc) Since we have USE_TZ = True in our config, using django.utils.timezone for datetime operations will use Django's timezone aware date objects, Django will handle the correct timezone application according to the configuration. If you're using the container, you can set the TZ environment variable to match your local timezone (e.g. TZ=America/New_York). Generally when dealing with dates and time, we should use the Django functions to make sure the timezone setting is respected. https://github.com/furthemore/APIS/blob/324bf13872fcca207805bd15c6ee763ceebf1a83/fm_eventmanager/settings.py.docker#L241 https://docs.djangoproject.com/en/5.1/topics/i18n/timezones/#naive-and-aware-datetime-objects — Reply to this email directly, view it on GitHub <#339 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAXYEBMONSXD2KO7WL4SOPT2H5AEBAVCNFSM6AAAAABUCRDLSCVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDKMRUHA3DMOBVGU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[rechner]

Namely the guide said to run python with -Wa and look for mention of deprecation warnings.

From the 5.0 deprecation docs I see:

• Support for pytz timezones will be removed.
• The USE_DEPRECATED_PYTZ transitional setting will be removed.
• The default value of the USE_TZ setting will change from False to True.

Your proposed changes are unrelated to the deprecation of pytz which appears in these migrations, and I suspect the only source of that deprecation warning:

APIS/registration/migrations/0034_auto_20161227_1230.py

Lines 7 to 15 in 324bf13

	import pytz
	from django.db import migrations, models
	PT = pytz.timezone("US/Pacific")
	class Migration(migrations.Migration):
	DEFAULT_DATETIME = PT.localize(datetime.datetime.now())

APIS/registration/migrations/0004_auto_20160729_0021.py

Lines 7 to 15 in 324bf13

	import pytz
	from django.db import migrations, models
	PT = pytz.timezone("US/Pacific")
	class Migration(migrations.Migration):
	DEFAULT_ORDER_MODIFIED_DATE = PT.localize(datetime.now())

We can replace the pytz usage there with Django's utility functions:

from django.utils import timezone

class Migration(migrations.Migration):
    DEFAULT_ORDER_MODIFIED_DATE = timezone.now()

[anadon]

Applied your requests for timezones and migrations. Once 2FA is re-added, I think we can cut this change set and have further changes as their own PRs. Does that sound correct?

[rechner]

Sounds good, just be sure to also revert my comments above where you changed handling to use UTC.

Another option for U2F library support is Django 4, which is still in-support and supported by our existing U2F library. If we do opt to switch to another library, it would be nice to include a migration to keep everyone from having to re-add their 2FA.

I also noticed your test for SQL server, you should be aware that APIS makes use of JSONField for payments, which is only supported by certain databases with native JSON types (limited to Postgres in Django 3, and MariaDB, MySQL, Oracle, PostgreSQL, and SQLite for Django 5).

[rechner]

I recommend strongly against breaking out the templates to suit themes or customization like this, it'll be a nightmare to maintain and test against. Ideally the Django templates should never change: Instead we should keep the behavior consistent and control custom themeable elements using CSS where possible, with configurable fields in settings.py or on the Event model, or by utilizing the Django sites framework.