Django-compressor: RemovedInDjango31Warning: Die Einstellung FILE_CHARSET ist veraltet

In der Versionshinweis heißt es:

Die Einstellung FILE_CHARSET ist veraltet. Ab Django 3.1 müssen von der Festplatte gelesene Dateien UTF-8-codiert sein.

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

Das damit verbundene Commit in Django:

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

Das Ticket:

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

Reicht es aus, nur alle settings.FILE_CHARSET im Django-Kompressor durch utf-8 zu ersetzen, um dieses Problem zu beheben, vielleicht ...?

Danke für die Berichterstattung. Das Ersetzen aller Vorkommen durch utf-8 kann für diejenigen, die diese Einstellung tatsächlich verwenden, zu Problemen führen. Die richtige Lösung wäre wahrscheinlich, die Einstellung zu verwenden, wenn sie vorhanden ist, und die fraglichen Parameter nicht festzulegen, wenn sie nicht vorhanden ist.

@ Karyon danke für deine Antwort. Ich habe versucht, einen Patch zu schreiben. Ich möchte, dass Sie überprüfen, ob mein Verständnis korrekt ist.

Dies ist das erste Mal, dass ich PR an dieses Repo sende, und ich habe möglicherweise etwas Wichtiges verpasst. Wenn Sie etwas falsch finden, lassen Sie es mich bitte wissen. Danke im Voraus.

behoben in # 934

Der neue Code scheint in meinem Setup eine sehr ähnliche Warnung auszulösen:

  /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

mit

django-compressor==2.3
Django==2.2.2

Es scheint, dass jeder Zugriff auf die Eigenschaft settings.FILE_CHARSET , selbst um zu testen, ob sie überschrieben wird, die Warnung auslöst. Und genau das tun wir, um zu überprüfen, ob wir die Standardeinstellung utf-8 .

Wenn wir die Abwärtskompatibilität beibehalten möchten, ist es am einfachsten, diese Warnung für diese bestimmte Codezeile mit folgender Funktion zu deaktivieren:

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

Wenn eine solche Lösung für Sie in Ordnung erscheint, kann ich eine PR bereitstellen.

Ja, eine PR wäre schön. Bei Bedarf können Sie zunächst die ursprüngliche PR zurücksetzen :)

Beim Schreiben des Patches für die PR stellte ich fest, dass die Warnung tatsächlich durch eine sehr seltsame Erkennung von is_overridden('FILE_CHARSET') ausgelöst wurde. Es scheint, dass in meinem Projekt, während ich in meinen Einstellungen nicht FILE_CHARSET festlege, is_overridden('FILE_CHARSET') True zurückgibt.

Aber wenn ich an einem minimalen Django-Projekt mit nur installiertem Django-Kompressor teste -> keine Warnung

Meine PR ist also in der Tat nicht erforderlich: is_overridden('FILE_CHARSET') sollte nicht True zurückgeben, daher sollten compress() und CompilerFilter() die Warnung nicht auslösen. Unter normalen Umständen.

Sogar der Test, den ich der Django-Kompressor-Codebasis hinzugefügt habe, um eine Regression auf dieser Warn-Pb zu erkennen, ist nicht besonders aussagekräftig: django / django @ 3d716467 commit (enthalten in django 3.1) hat diese Warnung gerade entfernt , nach dem Zeitplan für die

Das Schöne daran: Ich habe den Django-Kompressor anhand des neuen Django-Codes getestet (der, bei dem FILE_CHARSET und die zugehörige Warnung nicht mehr beendet werden) und er funktioniert ohne erkennbare Probleme.

Entschuldigung für die Unannehmlichkeiten. Ich denke, Sie können das Problem (wieder) schließen.