Changes between Initial Version and Version 1 of Ticket #35868
- Timestamp:
- Oct 26, 2024, 7:21:34 PM (6 days ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #35868 – Description
initial v1 1 1 Recently, Django 5.0 [https://docs.djangoproject.com/en/5.1/releases/5.0/#features-removed-in-5-0 removed] the `django.utils.timezone.utc` alias to `datetime.timezone.utc`. 2 2 3 I've written a custom file storage class that implements a `get_modified_time` method which, predictably, used the `django.utils.timezone.utc` alias. 3 I've written a custom file storage class that implements a `get_modified_time` method which, predictably, used the `django.utils.timezone.utc` alias. Use of this alias raises an `AttributeError` in Django 5.0. 4 4 5 5 The code in 'django/contrib/staticfiles/management/commands/collectstatic.py' reads as follows: … … 22 22 I assume the exception catch there is meant to ignore `AttributeError` exceptions from custom file storage classes that do not implement `get_modified_time`. This is inappropriate - custom file storage classes can be written by users, and the `get_modified_time` method may raise `AttributeError` for a completely unrelated reason. 23 23 24 The net effect of this is that when `collectstatic` was run, ''all'' static files were copied, regardless of modification time, as `collectstatic` silently ignored this error. This was difficult to pin down.24 The net effect of this is that due to the `AttributeError` raised by my own `get_modified_time` method, when `collectstatic` was run, ''all'' static files were copied, regardless of modification time, as `collectstatic` silently ignored this error. This was difficult to pin down. 25 25 26 26 Checking for the presence of a `get_modified_time` attribute using duck typing (eg. `hasattr(self.storage, 'get_modified_time')`) may be more appropriate than eating such a generic exception.