„uv“ ar „pip“: aštuonis kartus greičiau dar nereiškia visiško suderinamumo

Jei svarbiausia diegimo sparta, „uv“ verta išbandyti, bet esamo Python projekto nereikėtų perkelti vien pakeitus komandą. „Real Python“ švariame „JupyterLab“ diegimo bandyme „uv“ užtruko 2,618 s, o „pip“ – 21,409 s: tai maždaug aštuonis kartus greičiau tomis konkrečiomis sąlygomis.

Saugus pasirinkimas priklauso nuo to, ar po pakeitimo paketai atsidurs numatytoje Python aplinkoje, bus paimti iš tinkamo indekso ir išliks suderinamos jų versijos. Galima pradėti nuo „uv pip install“ ir palikti „requirements.txt“; perėjimas prie „pyproject.toml“ ir „uv.lock“ yra atskiras sprendimas, keičiantis projekto priklausomybių valdymą.

Ką parodo greičio bandymas

Vieno kompiuterio bandymas parodo konkretaus paketų rinkinio diegimo trukmę, o ne garantuotą pagreitėjimą kiekvienam projektui. Rezultatą veikia Python versija, operacinė sistema, tinklas, paketų dydis ir tai, ar priklausomybes reikia surinkti iš šaltinio. Todėl sekundes verta vertinti kartu su bandymo sąlygomis: trumpesnė komanda dar nepasako, ar galutinė aplinka bus tokia pati.

Ypač lengva supainioti diegimą į tuščią virtualiąją aplinką su pakartotine komanda aplinkoje, kurioje paketai jau įdiegti. Pirmuoju atveju įrankis turi parengti aplinką; antruoju didelė darbo dalis jau atlikta. Šiltas podėlis yra trečia situacija: virtualioji aplinka kuriama iš naujo, tačiau anksčiau atsisiųsti ar surinkti paketai gali būti panaudoti pakartotinai.

„requirements.txt“ ir „uv.lock“ reiškia skirtingas darbo eigas

„uv pip install -r requirements.txt“ leidžia išlaikyti dabartinį reikalavimų failą. Ši komanda savaime nepaverčia projekto „uv“ projekto darbo eiga ir nesukuria „uv.lock“. Tai tinkamas pirmas bandymas, kai norima įvertinti diegimo įrankį nekeičiant būdo, kuriuo komanda deklaruoja ir fiksuoja priklausomybes.

Oficialus perkėlimo vadovas aiškina, kad projekto režime „pyproject.toml“ aprašo priklausomybes, o „uv.lock“ fiksuoja išspręstas versijas, priklausomybių grupes ir kelioms platformoms reikalingus pasirinkimus. Jei projektas naudoja „requirements.in“ ir užfiksuotą „requirements.txt“, komanda „uv add -r requirements.in -c requirements.txt“ leidžia kuriant pirmą užraktą panaudoti senąsias versijas kaip apribojimus. Taip įrankio pakeitimas nesujungiamas su netyčiniu priklausomybių atnaujinimu.

Platformų skirtumas svarbus projektams, kuriuos ta pati komanda paleidžia, pavyzdžiui, „Linux“ ir „Windows“. Įprastai konkrečioje platformoje išspręstas „pip-tools“ reikalavimų rinkinys gali skirtis nuo kitoje platformoje išspręsto rinkinio; „uv.lock“ viename faile gali aprašyti abiem reikalingus pasirinkimus. Tačiau ir „uv pip compile --universal“ gali sukurti kelioms platformoms tinkamą „requirements.txt“, todėl universalumas nėra vien failo plėtinio savybė. Tikslinėse aplinkose vis tiek reikia įsitikinti, kad pasirinkti paketai įdiegiami ir projektas veikia.

Virtualioji aplinka ir nustatymai gali pakeisti rezultatą

„uv“ suderinamumo aprašas nurodo, kad „uv pip install“ naudoja aktyvią virtualiąją aplinką arba ieško neaktyvintos „.venv“ dabartiniame ar aukštesniame kataloge, o „pip“ tokios „.venv“ neieško ir be aktyvios aplinkos gali bandyti diegti į globalią Python aplinką. Vadinasi, dvi sėkmingai pasibaigusios komandos nebūtinai pakeičia tą patį Python interpretatorių. Bandymuose ir CI diegimo tikslą verta nurodyti aiškiai, o po diegimo patikrinti, kurį interpretatorių naudoja projekto komandos.

„uv“ taip pat neskaito „pip.conf“ ir „pip“ skirtų aplinkos kintamųjų, tokių kaip „PIP_INDEX_URL“. Jei priklausomybės gaunamos iš privataus indekso, ankstesni „pip“ nustatymai automatiškai nepersikels: „uv“ turi savus konfigūracijos failus ir aplinkos kintamuosius. Prieš lyginant greitį reikia sulyginti indekso adresą bei prieigą, antraip įrankiai gali spręsti priklausomybes iš skirtingų paketų rinkinių.

Trys atkuriami diegimo scenarijai

Visiems scenarijams naudokite tą patį „requirements.txt“, Python interpretatorių, paketų indeksą ir įrenginį. Toliau pateiktos komandos skirtos „Unix“ tipo apvalkalui ir atskirai bandomajai projekto kopijai. Matuokite diegimo komandą, o virtualiųjų aplinkų kūrimo laiką užrašykite atskirai; kitaip palyginimas apims skirtingas užduotis.

1. Švarus diegimas. Sukurkite naujas aplinkas komandomis „python3 -m venv .bench/pip“ ir „uv venv .bench/uv --python python3“. Kiekvienam įrankiui naudokite naują, tuščią podėlio katalogą. Tada matuokite „.bench/pip/bin/python -m pip install -r requirements.txt“ ir „uv pip install --python .bench/uv/bin/python -r requirements.txt“. Užrašykite Python versiją, indekso adresą ir tai, ar paketai buvo renkami iš šaltinio.
2. Šiltas podėlis. Pašalinkite tik bandomąsias virtualiąsias aplinkas, palikdami abiejų įrankių podėlius. Sukurkite aplinkas iš naujo ir pakartokite tas pačias diegimo komandas su tais pačiais podėlio katalogais. Taip matuosite naujos aplinkos parengimą iš jau turimų duomenų, o ne pakartotinį diegimą į aplinką, kurioje priklausomybės tebėra.
3. CI vykdymas. Vienodos konfigūracijos užduotyse kiekvieną kartą kurkite naują aplinką ir diekite tą patį reikalavimų failą su „pip install -r requirements.txt“ bei „uv pip install -r requirements.txt“. Atskirai matuokite užduotis be išsaugoto podėlio ir su išsaugotu podėliu. Jei projektas jau naudoja „uv.lock“, „uv sync --locked“ matuokite kaip atskirą projekto darbo eigą, nes ji kartu tikrina užrakto atitiktį projekto metaduomenims.

CI podėlio dydis pats savaime negarantuoja trumpesnės užduoties. „uv“ podėlio dokumentacijoje pažymima, kad iš anksto paruoštus paketus kartais greičiau atsisiųsti iš naujo, o iš šaltinio surinktus paketus dažnai verta išsaugoti. Todėl CI rezultatą vertinkite pagal visos užduoties trukmę, įskaitant podėlio atkūrimą, o ne vien pagal pačios diegimo komandos laiką.

Kaip perkelti esamą projektą nepaslepiant skirtumų

Pirmiausia palikite seną reikalavimų failą ir naujoje bandomojoje aplinkoje pakeiskite tik diegimo įrankį. Palyginkite įdiegtų paketų versijas, naudojamą Python interpretatorių, privačių indeksų nustatymus ir projekto testų rezultatus. Jei atsiranda skirtumas, šiame etape lengviau nustatyti, ar jį sukėlė paketų sprendimas, diegimo tikslas, ar konfigūracija.

Prieš pereidami prie projekto režimo, atskirai peržiūrėkite kūrimo ir pasirenkamas priklausomybes, platformų žymeklius, vietinius bei „Git“ paketus. Ankstesnių versijų apribojimai naudingi pirmam „uv.lock“, tačiau skirtingoms platformoms parengti seni failai gali reikalauti papildomo žymeklių sutvarkymo. Perkėlimą užbaikite tik tada, kai tikslinėse aplinkose praeina tie patys testai ir aišku, kurios priklausomybių grupės turi būti įdiegtos.

Projekto režime keičiasi ir sinchronizavimo pasekmė. Pagal „uv“ užrakinimo ir sinchronizavimo taisykles „uv sync“ pagal numatytuosius nustatymus pašalina paketus, kurių nėra užrakto faile, o „--locked“ pateikia klaidą, jei užraktą reikėtų atnaujinti. Tai padeda CI gauti apibrėžtą aplinką, tačiau senoje kūrėjo aplinkoje gali pašalinti rankiniu būdu pridėtus paketus. Todėl perėjimą tikrinkite naujai sukurtoje aplinkoje, o sprendimą dėl „uv.lock“ priimkite po paprastesnio diegimo palyginimo.

Taip pat skaitykite:

• ESA ir Mistral jungia DI su kosmosu, bet susitarimas dar be projektų
• YouTube ar Spotify tinklalaidei: RSS importas dar nereiškia platinimo
• ChatGPT ar Gemini „Deep Research“: šaltinių gausa dar nereiškia tikslumo