Wycofać git-pin django-import-export po wydaniu 4.4.2 (upstream #2156)

[mpasternak]

Kontekst

pyproject.toml ([tool.uv.sources]) tymczasowo pinuje django-import-export na git-tag naszego forka zamiast PyPI:

[tool.uv.sources]
django-import-export = { git = "https://github.com/mpasternak/django-import-export.git", tag = "4.4.2.dev0+iplweb" }

Tag 4.4.2.dev0+iplweb = main HEAD forka (d6ee0d3, = 4.4.1 + 49 commitów upstream).

Dlaczego

Fix django-import-export#2156 ("Loading format libraries now checks IMPORT_EXPORT_FORMATS to improve performance") przeniósł budowanie listy formatów z eager module-level DEFAULT_FORMATS = [... if is_available()] do leniwej @lru_cache get_default_formats().

Efekt w BPP: openpyxl (i przez nie numpy) przestają się ładować przy admin.autodiscover (django.setup()), bo is_available() nie jest już wołane przy imporcie. RSS przy setupie spada ~154 → ~144 MB; openpyxl/numpy wchodzą dopiero przy realnym eksporcie XLSX (a nie w każdym procesie web/Celery przy starcie).

Fix jest zmergowany w upstream main, ale niewydany — ostatni release PyPI to 4.4.1, który ma jeszcze stary eager probe.

Akcja do wykonania (gdy upstream wyda 4.4.2 / 4.5 z #2156)

1. Usunąć blok [tool.uv.sources] dla django-import-export z pyproject.toml.
2. Podbić constraint na wydaną wersję (np. django-import-export>=4.4.2,<5).
3. uv lock && uv sync; sprawdzić git+... zniknęło z uv.lock.
4. Usunąć tag 4.4.2.dev0+iplweb z forka (opcjonalnie).
5. Walidacja: openpyxl/numpy nadal nie-eager przy django.setup() (RSS ~144 MB), testy admin-export zielone.

Powiązania

• Upstream PR: Loading format libraries now checks IMPORT_EXPORT_FORMATS to improve performance django-import-export/django-import-export#2156
• Wprowadzone w PR perf(memory): MALLOC_ARENA_MAX + recykling appservera (gunicorn) + lazy-import ciężkich zależności #279 (perf: redukcja pamięci appserver/Celery)

[mpasternak]

Hardening pinu (z automated security review PR #279)

Pin używa immutable rev (commit SHA) zamiast tag (commit 4402ffffe):

[tool.uv.sources]
django-import-export = { git = "...mpasternak/django-import-export.git", rev = "d6ee0d39194fee31437affbdc6fee5ce549b4b8f" }

Zasady utrzymania:

• Każdy przyszły bump tego pinu MUSI jawnie zmienić rev SHA — nie "śledzimy taga/brancha" (tag jest przesuwalny → supply-chain).
• Docelowo (gdy 4.4.2/4.5 wyjdzie na PyPI): usunąć cały blok [tool.uv.sources], wrócić na django-import-export>=4.5 z PyPI (wheel), uv lock && uv sync.

Opcjonalne, większe hardeningi (do rozważenia, nie blokują):

• Przenieść fork pod org iplweb z branch protection + required reviewers + 2FA (zamiast konta osobistego).
• Dodać regułę CI/uv-secure, która faila, gdy wpis w [tool.uv.sources] używa tag/branch zamiast rev.