Aktualizacja do Django 6.1

[mpasternak]

Django 6.1

Aktualizacja BPP z Django 5.2.16 LTS do Django 6.1 (wydane 2026-08-05).

Co się zmienia

• Django 6.1, requires-python podniesione do >= 3.12 (wymóg 6.1; 3.11 wypadło razem z 6.0). Obraz Dockera i główne CI już stały na 3.12, więc nic tam nie trzeba ruszać.
• django-prometheus usunięty. Miał twardy cap Django<6.1. Integracja była w całości opcjonalna (DJANGO_BPP_ENABLE_PROMETHEUS, domyślnie False) — poszła razem z flagą, middleware, wpisem w INSTALLED_APPS i routingiem /metrics.
• Powrót z django-redis-iplweb na upstreamowy django-redis. Fork był czystym republishem (zero kodu iplweb, ten sam moduł django_redis) i utknął na Django<6.1; upstream 7.0.0 deklaruje Django<7.0,>=5.2. Nazwa backendu w konfiguracji się nie zmienia, więc wdrożenia nie wymagają żadnej akcji.
• Grappelli bez zmian — 5.0.0 jest już linią dla Django 6.x (numeracja Grappelli jest przesunięta o jeden wstecz względem Django: 5.0.x → Django 6.x, 4.0.x → Django 5.x). Dodany komentarz przy pinie, bo dependabot raz już podbił to w złą stronę.

Naprawione regresje Django 6.1

Każda potwierdzona kontrolą: test przechodzi na 5.2, oblewa na 6.1, przy niezmienionym otoczeniu.

1. ForwardManyToOneDescriptor.get_queryset() wymaga instance (bpp/admin/core.py)
W 6.1 metoda dokłada .fetch_mode() ze stanu instancji, więc ma sygnaturę keyword-only instance. BPP wołało ją w czasie definicji klasy formularza, gdzie instancji nie ma. Zastąpione sięgnięciem po _base_manager wprost — dokładnie to, co deskryptor robił pod spodem. _base_manager, nie _default_manager: pole musi widzieć rekordy odfiltrowane przez managera domyślnego (soft-delete).

2. Aliasy SELECT-a są konsekwentnie cytowane (raport_slotow/core.py)
ProgrammingError: kolumna "col2" nie istnieje. Autor_Dyscyplina.Meta.ordering = ('rok',), a rok to druga kolumna w values(). Wymagało trzech pustych .order_by(): na obu operandach union(), na jego wyniku i na wyniku difference() — ten ostatni dlatego, że raport_slotow/models/uczelnia.py woła na nim values_list(), co klonuje zapytanie razem z flagą domyślnego sortowania.

3. BaseModelForm.validate_constraints() — metoda nowa w 6.1 (bpp/admin/projekt.py)
W 5.2 nie istniała; Model.validate_constraints jest w obu wersjach identyczne. Skutek: podmiana kierownika projektu w jednym zapisie przestawała przechodzić, bo stary wiersz oznaczony DELETE wciąż jest w bazie. Django koordynuje walidację między formularzami tylko dla unikalności (BaseModelFormSet.validate_unique() odsiewa deleted_forms); dla constraintów odpowiednika nie ma. Walidacja per-wiersz wyłączona w dedykowanym Projekt_AutorForm; odsiew robi istniejący Projekt_AutorFormSet.clean(), a constraint w bazie zostaje jako ostatnia linia obrony.

4. Script.__str__ renderuje przez staticfiles storage (bpp/tests/test_zapytanie.py)
Do 6.0 str(Script(...)) nie zawierało content-hasha; teraz zawiera (highlight.js → highlight.f65f9cbe99ea.js). Asercja dopasowuje nazwę tolerując hash, zamiast porównywać literał.

Dług techniczny wprowadzony świadomie

Co	Dlaczego	Status
djangorestframework z gita (80d535dd)	DRF 3.17.2 (najnowsze na PyPI) wciąż importuje cc_delim_re, usunięte w 6.1 → ImportError na całym api_v1. Fix jest na main upstreamu, ale 3.18.0 nie zostało wydane.	ZOSTAJE — decyzja świadoma. Nie czekamy na 3.18.0. Konsekwencja: DRF wypada z pip-audit (URL requirements) i buduje się ze źródeł. Pin wskazuje na SHA na main, więc jest trwały (w odróżnieniu od gałęzi feature'owej). Wymiana na >=3.18 to jedna linijka, gdy wydanie się pojawi.
django-pbn-client z gita	PyPI 0.2.2 miało cap django<5.3.	ZDJĘTE — 0.2.3 wydane 2026-08-07, wraca z rejestru PyPI (ee5e81a35).
Shim django.utils.itercompat w django_bpp/compat.py	django-admin-tools 0.9.3 (ostatnie wydanie: sierpień 2023, klasyfikatory do Django 4.0) ma martwy import usuniętego modułu.	Zostaje — do zdjęcia razem z odejściem od django-admin-tools albo po forku z usuniętą tą linią.

Dodatkowo podniesiony floor h2>=4.4.1 (CVE-2026-71554) w constraint-dependencies. CVE dotyczyło tak samo dev — tam h2 również było 4.3.0; złapane przy okazji, bo dev nie miał przebiegu pip-audit od publikacji CVE.

Przed produkcją warto obejrzeć panel admina — Django 6.1 przebudowało układ formularzy admina (usunięte wide, object-tools poza blokiem content), a w repo jest 64 nadpisanych szablonów. Testy sprawdzają zachowanie, nie layout. Szczegóły w komentarzu do PR-a.

Czego świadomie NIE ma w tym PR

• Sprzątania deprecacji 6.1 (BLANK_CHOICE_DASH, transaction.savepoint(), gołe select_related(), action_location, EMAIL_* → MAILERS). To warningi, nie błędy — filterwarnings = default, więc nic nie blokują. Osobny PR, żeby ten miał jeden czytelny sygnał.
• Zmian w docs.yml (Python 3.11): ten workflow nie instaluje projektu, tylko docs/requirements.txt + mkdocs build, więc requires-python go nie dotyczy.

Weryfikacja

• manage.py check — czysto.
• makemigrations --check — dryf istnieje (favicon, flexible_reports, siteblog, wewnątrz .venv), ale identyczny na 5.2: stan zastany, nie skutek tego PR-a.
• Audyt uv.lock: z 365 pakietów zniknęło sześć — pięć backportów dla Pythona <3.12 (async-timeout, backports-tarfile, importlib-metadata, tomli, zipp) plus podmieniony fork Redisa. Reszta dużego diffu to metadane gałęzi rozwiązania dla 3.10/3.11.

[mpasternak]

Gotowość do merge'u — co jest sprawdzone, a co nie

Co merge do dev faktycznie uruchamia

Push do dev odpala wyłącznie Docs, Refresh baseline pg_dump i Tests. Żadnego deploya, żadnego budowania obrazów produkcyjnych. Produkcja idzie osobno i ręcznie: make release-candidate → :staging → test → make release-promote → :latest. Merge tego PR-a niczego nie wysyła użytkownikom i jest odwracalny zwykłym git revert.

Co jest zweryfikowane

• Pełna suita z Playwrightem włącznie — shardy CI pokrywają cały zestaw (tests.yml:282: „Single sharded job covering the full suite (playwright + non-playwright + serial)"), więc testy przeglądarkowe też przeszły na 6.1.
• 12/12 shardów, Build test-runner image, pip-audit, uv.lock in sync, Check baseline freshness — zielone. 24 checki, zero nie-pass.
• Lokalnie: 9308 zdanych, manage.py check czysto.
• Dryf makemigrations --check identyczny jak na 5.2 — stan zastany, nie skutek tego PR-a.
• django-redis 6.0.1 (fork) → 7.0.0 (upstream) przez major: sprawdzone, że BPP używa wyłącznie stringa BACKEND, bez get_redis_connection i bez metod hash/sorted-set, które 7.0 przemianowało. Nazwa backendu w konfiguracji się nie zmienia → wdrożenia nie wymagają akcji.

Czego testy NIE sprawdzają — jedyna istotna luka

Wygląd panelu admina. Django 6.1 usunęło klasę CSS wide, wyniosło object-tools poza blok content i przebudowało układ pól formularza (etykiety / help / błędy). W repo jest 64 nadpisanych szablonów admina, a Grappelli 5.0.0 dopiero teraz trafiło na Django, dla którego było pisane (linia 5.0.x = Django 6.x).

Testy sprawdzają zachowanie, nie layout — rozjechany formularz przejdzie przez zielone CI niezauważony. To warto obejrzeć okiem: run-site run --from-dump <dump>, wejść w wydawnictwo ciągłe z inline'ami autorów, autora i źródło.

Koszt dla zespołu

Po merge'u każda żywa gałąź feature'owa musi się przerebase'ować na Django 6.1 i przesynchronizować własny venv — requires-python skoczyło do 3.12, a z locka wypadło pięć backportów dla starszych Pythonów. To nie ryzyko techniczne, tylko tarcie, ale warto uprzedzić zainteresowanych przed merge'em.

Decyzja: djangorestframework zostaje na pinie z gita

Pierwotnie ten PR zakładał zdjęcie pinu po wydaniu DRF 3.18.0 (PR encode/django-rest-framework#10015, wciąż otwarty). Świadoma decyzja: nie czekamy — wchodzimy z pinem na commit 80d535dd z gałęzi main upstreamu.

Uczciwie o konsekwencjach, żeby nikt nie odkrył ich później przypadkiem:

• pip-audit nie skanuje DRF, dopóki jest z URL-a (URL requirements cannot be pinned to a specific package version). DRF to duża zależność sieciowa — to realna, choć zaakceptowana, dziura w audycie. Dopóki tak jest, CVE w DRF nie zostanie wykryte automatycznie.
• Git-source buduje ze źródeł, czyli wykonuje setup.py przy instalacji — jawny wyjątek od polityki wheel-only opisanej w pyproject.toml. Trzeci taki wyjątek w projekcie, obok django-import-export.
• Trwałość pinu jest tu jednak dobra, inaczej niż w zdjętym już przypadku django-pbn-client: tamten wskazywał na commit niezmergowanej gałęzi feature'owej, która po merge'u znika i psuje build. Ten wskazuje na SHA na main, który pozostaje osiągalny — więc build się nie rozsypie.

Do zrobienia przy okazji, gdy DRF 3.18.0 się pojawi: zamienić wpis w [tool.uv.sources] na djangorestframework>=3.18 i uv lock. Jedna linijka; komentarz przy pinie opisuje warunek wyjścia.

Znany flake, niezwiązany z tym PR-em

komparator_pbn_udzialy::test_problem_wrapper_for_rozbieznosc padł raz na IntegrityError (kod=3.314), po czym przeszedł przy ponownym uruchomieniu; lokalnie 15 powtórzeń pod rząd zielonych. Przyczyna: baker.make("bpp.Dyscyplina_Naukowa", ...) bez jawnego kod przy unikalnym polu — pięć miejsc (test_models.py 158/159/193, test_views.py 47/48). git diff dev...django-6.1 -- src/komparator_pbn_udzialy/ jest pusty, więc to nie regresja z tej migracji. Do naprawy osobnym PR-em.