From 23798cda017fb590309a110d85c823624850b201 Mon Sep 17 00:00:00 2001 From: marwin Date: Fri, 28 Aug 2026 08:50:47 +0000 Subject: [PATCH] =?UTF-8?q?Alle=20Abh=C3=A4ngigkeiten=20pinnen;=20STATICFI?= =?UTF-8?q?LES=5FSTORAGE=20auf=20STORAGES=20umstellen?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit requirements.txt stand durchgehend auf ">=", die gebaute Version hing also am Kalendertag statt am Repo. Genau daran ist der letzte Deploy gescheitert. Jetzt exakt die Versionen, gegen die die Suite grün ist und die produktiv laufen — Updates werden damit zu einer bewussten Änderung mit CI-Lauf. Django bleibt auf 6.1: dorthin ist die Instanz ohnehin schon gedriftet, es läuft, und 4.2 LTS ist seit April 2026 aus dem Support. Dabei ist aufgefallen, dass Django 5.1 STATICFILES_STORAGE entfernt hat. Die Einstellung stand noch da und wurde stillschweigend ignoriert, womit whitenoise auf StaticFilesStorage zurückfiel und Assets unkomprimiert auslieferte — app.js mit 251 KB statt 62 KB bei jedem kalten Laden. Co-Authored-By: Claude Opus 5 --- diora/settings.py | 18 +++++++++++++++++- requirements.txt | 29 +++++++++++++++++------------ 2 files changed, 34 insertions(+), 13 deletions(-) diff --git a/diora/settings.py b/diora/settings.py index b8c8b21..9a4e865 100644 --- a/diora/settings.py +++ b/diora/settings.py @@ -97,7 +97,23 @@ STATIC_URL = '/static/' STATICFILES_DIRS = [BASE_DIR / 'static'] STATIC_ROOT = BASE_DIR / 'staticfiles' -STATICFILES_STORAGE = 'whitenoise.storage.CompressedManifestStaticFilesStorage' +# Django 5.1 removed STATICFILES_STORAGE in favour of STORAGES. The old setting +# sat here being silently ignored, so whitenoise fell back to plain +# StaticFilesStorage and served everything uncompressed — app.js went out at +# 251 KB instead of 62 KB on every cold load. +# +# The hashed filenames this also generates are inert: no template uses +# {% static %}, they all hardcode /static/… paths. Cache busting comes from the +# service worker's CACHE version instead (static/js/sw.js), which is why it is +# bumped on each release. +STORAGES = { + 'default': { + 'BACKEND': 'django.core.files.storage.FileSystemStorage', + }, + 'staticfiles': { + 'BACKEND': 'whitenoise.storage.CompressedManifestStaticFilesStorage', + }, +} MEDIA_URL = '/media/' MEDIA_ROOT = BASE_DIR / 'media' diff --git a/requirements.txt b/requirements.txt index 5841df5..457e64d 100644 --- a/requirements.txt +++ b/requirements.txt @@ -1,13 +1,18 @@ -django>=4.2 -pylast>=5.2 -requests>=2.31 -python-dotenv>=1.0 -whitenoise>=6.6 -feedparser>=6.0 -gevent>=24.0 -# Pinned: 26.2.0 ships ggevent.py importing packaging.version while declaring -# no dependencies at all, so the gevent worker dies at boot unless packaging is -# installed explicitly. Both stay pinned here rather than being pulled in bare -# by the Dockerfile, so a rebuild cannot silently change the worker again. +# Pinned to exact versions. These are what production runs and what the test +# suite is green against — with `>=` the image you get depends on the day you +# build it, which is how a rebuild once swapped in a gunicorn that could not +# boot the gevent worker at all. +# +# Nothing here updates on its own any more, so bump deliberately: change a +# version, let CI run, then deploy. +Django==6.1 +pylast==7.1.0 +requests==2.34.2 +python-dotenv==1.2.3 +whitenoise==6.12.0 +feedparser==6.0.14 +gevent==26.8.0 +# gunicorn 26.2.0 imports packaging.version in ggevent.py while declaring no +# dependencies of its own, so packaging has to be requested explicitly. gunicorn==26.2.0 -packaging>=24.0 +packaging==26.3