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 <noreply@anthropic.com>
18 lines
679 B
Text
18 lines
679 B
Text
# 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==26.3
|