Django-compressor: RemovedInDjango31Warning: Le paramètre FILE_CHARSET est obsolète

La note de publication dit:

Le paramètre FILE_CHARSET est obsolète. À partir de Django 3.1, les fichiers lus à partir du disque doivent être encodés en UTF-8.

• https://docs.djangoproject.com/en/2.2/releases/2.2/#id2

Le commit associé dans Django:

https://github.com/django/django/commit/0cd465b63aa7c03a3d14bd5fd6543628d585f8da

Le billet:

https://code.djangoproject.com/ticket/29817

Est-il suffisant de remplacer tout settings.FILE_CHARSET dans django-compresseur par utf-8 pour résoudre ce problème, peut-être ...?

merci pour le rapport. remplacer toutes les occurrences par utf-8 pourrait casser des choses pour ceux qui utilisent réellement ce paramètre. le correctif approprié serait probablement d'utiliser le paramètre s'il est présent, et de ne pas définir les paramètres en question s'il n'est pas présent.

@karyon merci pour votre réponse. J'ai essayé d'écrire un patch. J'aimerais que vous vérifiiez si ma compréhension est correcte.

C'est la première fois que j'envoie des relations publiques à ce repo et j'ai peut-être manqué quelque chose d'important. Si vous trouvez quelque chose de mal, faites-le moi savoir Merci d'avance.

corrigé dans # 934

Le nouveau code semble provoquer un avertissement très similaire dans ma configuration:

  /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

avec

django-compressor==2.3
Django==2.2.2

Il semble que tout accès à la propriété settings.FILE_CHARSET , même pour tester si elle est remplacée, déclenchera l'avertissement. Et c'est exactement ce que nous faisons pour vérifier si nous devons utiliser la utf-8 par défaut

Si nous voulons conserver la compatibilité descendante, le moyen le plus simple est de désactiver cet avertissement pour cette ligne spécifique du code en utilisant quelque chose comme ceci:

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

Si une telle solution vous convient, je peux vous fournir un PR.

oui, un PR serait bien. si nécessaire, vous pouvez commencer par revenir au PR d'origine :)

En écrivant le patch pour le PR, j'ai découvert que l'avertissement était en fait déclenché par une détection de falty très étrange de is_overridden('FILE_CHARSET') . Il semble que dans mon projet alors que je ne règle pas FILE_CHARSET dans mes paramètres, is_overridden('FILE_CHARSET') renvoie True.

Mais si je teste sur un projet django minimal avec juste django-compresseur installé -> pas d'avertissement

Donc, mon PR n'est en fait pas nécessaire: is_overridden('FILE_CHARSET') ne devrait pas retourner True donc compress() et CompilerFilter() ne devraient pas déclencher l'avertissement. Dans des circonstances normales.

Même le test que j'ai ajouté à la base de code de django-compresseur pour détecter toute régression sur cet avertissement pb, n'est pas tellement ineressting: django / django @ 3d716467 commit (inclus dans bientôt à venir django 3.1) vient de supprimer ledit avertissement , suivant la chronologie de la dépréciation de django .

Bon côté des choses: j'ai testé le compresseur django avec le nouveau code django (celui où FILE_CHARSET et l'avertissement associé ne se terminent plus) et cela fonctionne sans aucun problème détectable.

Désolé pour le dérangement. Je pense que vous pouvez clore (à nouveau) le problème.