uv przekroczyło 86 000 gwiazdek na GitHubie, zachowując się mniej jak instalator pakietów, a bardziej jak strategia. Rustowy toolchain od Astral już wchłonął pip, venv, pyenv i pipx w jedną binarkę, a wydanie 0.11.19 z 3 czerwca 2026 pokazuje, że apetyt nie jest zaspokojony. Przewijają się przez nie dwa wątki: zacieśnić łańcuch dostaw i dalej poszerzać powierzchnię, którą uv pokrywa.
Zacznijmy od łańcucha dostaw, bo to zmiana, na której korzystają wszyscy, a nikt jej nie zauważy. uv 0.11.19 liczy teraz zawsze SHA256 dla zdalnych dystrybucji. To mało efektowna hydraulika, która sprawia, że lockfile coś znaczy: hash zapisany dziś to hash, który zweryfikujesz na każdej maszynie rozwiązującej to samo drzewo zależności jutro. Dla narzędzia, którego cała obietnica to powtarzalne, szybkie instalacje, hashowanie wszystkiego domyślnie to funkcja, która powinna mieć paradę, a dostaje jedną linijkę w changelogu.
Bardziej wymowna zmiana pojawiła się dzień wcześniej. uv 0.11.18 dodało uv check, które uruchamia ty, własny type checker Astral, bezpośrednio z poziomu uv jako podgląd. Przeczytaj to powoli. Menedżer pakietów ma teraz podkomendę, która sprawdza typy w Twoim kodzie. uv 0.11.19 dorzuciło następnie platformę PyEmscripten z PEP 783 oraz target triple Pyodide 2025, co oznacza, że uv uczy się też celować w Pythona w przeglądarce przez WebAssembly. Instalator staje się instalatorem, resolverem, runnerem, type checkerem i menedżerem celów cross-kompilacji naraz.
Oto, po co uv teraz sięga, w zestawieniu z jednozadaniowymi narzędziami, które zastępuje:
Comparison data
| Instaluje Pythona | Rozwiązuje + lockuje | Uruchamia narzędzia | Sprawdza typy | |
|---|---|---|---|---|
| uv | Yes | Yes | Yes | ty (podgląd) |
| pip + venv | No | No | No | No |
| poetry | No | Yes | No | No |
| pyenv | Yes | No | No | No |
| pipx | No | No | Yes | No |
Nic z tego nie jest zarzutem do jakości. uv jest szybkie, resolver jest dobry, a scalenie pięciu narzędzi w jedno faktycznie usuwa całą kategorię bólu "który Python, który venv, który lockfile", który kosztował zespoły Pythona lata. Praca nad łańcuchem dostaw to z gatunku tych rzeczy, które docenia się dopiero po cudzym incydencie z dependency confusion.
Szczere zastrzeżenie jest strukturalne, nie techniczne. Kiedy Twój instalator, resolver, runner zadań i teraz type checker pochodzą od tego samego dostawcy w tym samym tempie wydań, nie wdrożyłeś tylko narzędzia. Wystandaryzowałeś cały swój punkt wejścia do Pythona na Astral. To prawdopodobnie dobry zakład w tym momencie, biorąc pod uwagę wykonanie. To wciąż zakład, a moment, żeby to zauważyć, jest, zanim uv check będzie jedynym type checkerem, który Twoje CI potrafi wywołać, a nie po.
Używaj uv. Przypnij wersję, pozwól mu liczyć hashe pobrań i wypróbuj uv check, póki jest podglądem, na który się piszesz, a nie domyślną opcją, którą odziedziczysz.