Changes between Initial Version and Version 1 of Ticket #35868


Ignore:
Timestamp:
Oct 26, 2024, 7:21:34 PM (4 weeks ago)
Author:
Brett G
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #35868 – Description

    initial v1  
    11Recently, 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`.
    22
    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.
     3I'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.
    44
    55The code in 'django/contrib/staticfiles/management/commands/collectstatic.py' reads as follows:
     
    2222I 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.
    2323
    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.
     24The 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.
    2525
    2626Checking 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.
Back to Top