I met the following warning when I ran a test with my Django environment.
/path/to/lib/python3.7/site-packages/compressor/filters/base.py:115: RemovedInDjango31Warning: The FILE_CHARSET setting is deprecated. Starting with Django 3.1, all files read from disk must be UTF-8 encoded.
default_encoding = settings.FILE_CHARSET
It seems that the usage of settings.FILE_CHARSET
is discouraged.
Deprecated since version 2.2:
This setting is deprecated. Starting with Django 3.1, files read from disk must be UTF-8 encoded.
versions:
The release note says:
The
FILE_CHARSET
setting is deprecated. Starting with Django 3.1, files read from disk must be UTF-8 encoded.
The related commit in Django:
https://github.com/django/django/commit/0cd465b63aa7c03a3d14bd5fd6543628d585f8da
The ticket:
Is it enough just to replace all settings.FILE_CHARSET
in django-compressor to utf-8
to address this issue, maybe...?
thanks for reporting. replacing all the occurrences with utf-8
might break things for those who actually use this setting. the proper fix would probably be to use the setting if it's present, and not set the parameters in question if it's not present.
@karyon thank you for your response. I tried writing a patch. I'd like you to review if my understanding is correct.
This is the first time for me to send PR to this repo and I might have missed something important. If you find anything wrong, please let me know. Thank you in advance.
fixed in #934
The new code seems to cause a very similar warning in my setup:
/usr/local/lib/python3.7/site-packages/compressor/filters/base.py:123: RemovedInDjango31Warning: The FILE_CHARSET setting is deprecated. Starting with Django 3.1, all files read from disk must be UTF-8 encoded.
settings.FILE_CHARSET if settings.is_overridden('FILE_CHARSET') else
with
django-compressor==2.3
Django==2.2.2
It appears that any access to settings.FILE_CHARSET
property, even to test if it is overridden, will trigger the warning. And this is exactly what we do to check if we need to use the utf-8
default.
If we want to keep backward compatibility the simplest way is to disable this warning for this specific line of the code using something like this:
import warnings
with warnings.catch_warnings():
warnings.filterwarnings("ignore", message="popo popo")
warnings.warn("popo popo") # the code that will trigger the warning
# warnings are back to normal filtering from here
If such solution seems ok for you I can provide a PR.
yes, a PR would be nice. if necessary you can start by reverting the original PR :)
While writting the patch for the PR I discovered the warning was in fact triggered by a very weird falty detection of is_overridden('FILE_CHARSET')
. It seems that in my project whereas I do not set FILE_CHARSET
in my settings, is_overridden('FILE_CHARSET')
returns True.
But if I test on an minimal django project with just django-compressor installed --> no warning
So my PR is in fact not necessary: is_overridden('FILE_CHARSET')
should not return True therefore compress()
and CompilerFilter()
should not raise the warning. Under normal circonstancies.
Even the test I added to the django-compressor code base to detect any regression on this warning pb, are not that much ineressting : django/django@3d716467 commit (included in soon-to-come django 3.1) has just removed the said warning, following the django deprecation timeline.
Bright side of things: I tested the django-compressor against the new django code (the one where FILE_CHARSET
and associated warning does not exit anymore) and it works without any detectable problem.
Sorry for the inconvenience. I think you can close (again) the issue.
Most helpful comment
It appears that any access to
settings.FILE_CHARSET
property, even to test if it is overridden, will trigger the warning. And this is exactly what we do to check if we need to use theutf-8
default.If we want to keep backward compatibility the simplest way is to disable this warning for this specific line of the code using something like this:
If such solution seems ok for you I can provide a PR.