pip-ээс uv рүү шилжихэд хурд хангалтгүй: таван нийцлийн занга бий

Одоо байгаа Python төслийг pip-ээс uv рүү шилжүүлэхдээ requirements файлаа хадгалж, тусдаа virtual environment-д uv pip командаар суулгалт, тест, CI-г давт. Тэдгээр нь амжилттай болсны дараа pyproject.toml ба uv.lock руу шилжиж болно. uv-ийн pip нийцлийн баримт тохиргоо, keyring нэвтрэлт, resolver-ийн хатуу шалгалт, CLI сонголт, bytecode гэсэн таван ялгааг тайлбарладаг.

Хуучин requirements файл болон pip ашигладаг CI ажлыг шилжилтийн турш хадгал. Ингэснээр шинэ суулгалт амжилтгүй болбол өмнөх багцын хувилбар, индексийн тохиргоо, ажиллаж байсан командыг сэргээх суурь үлдэнэ. uv pip нь одоогийн файлуудтай ажиллах боломж олгодог; uv.lock руу орох нь үүнээс тусдаа шийдвэр юм.

Requirements файлын үүргийг тогтоо

Эхлээд requirements.txt дотор шууд бус хамаарлуудын хувилбар хүртэл түгжигдсэн эсэхийг шалга. pip-tools хэрэглэдэг төсөлд requirements.in нь шууд хамаарлыг, түүнээс гаргасан requirements.txt нь суулгах багцуудыг жагсаах нь түгээмэл. Харин requirements.txt дотор зөвхөн дээд түвшний багцууд байвал түүнийг бүрэн түгжээ гэж үзэж болохгүй: суулгах бүрд resolver шууд бус хамаарлын хувилбарыг дахин сонгож болно.

Эхний солилцоонд хуучин python -m pip install -r requirements.txt командын оронд uv pip install -r requirements.txt хэрэглэж, файлыг тэр дор нь дахин үүсгэхгүй. Индекс, локал зам, editable суулгалт, Git хамаарал болон нэмэлт requirements файлыг мөн авч үз. Хуучин орчноос python -m pip freeze гаргавал хувилбаруудыг харьцуулах суурь болно, гэхдээ түүнд төсөлд шаардлагагүйгээр суусан багц ч орж болдог. Тиймээс зөвхөн freeze-ийн мөр таарсныг бус, төслийн тест ба эхлүүлэх ажиллагааг шалгана.

Virtual environment-ийг тусад нь байгуул

Ажиллаж буй .venv-г дарж бичихгүйгээр төслийн тусдаа хуулбарт цэвэр орчин үүсгэ. Linux CI ажлын хуучин дараалал python -m venv .venv, дараа нь .venv/bin/python -m pip install -r requirements.txt байсан бол шинэ дараалал uv venv .venv, дараа нь uv pip install --python .venv/bin/python -r requirements.txt байж болно. --python сонголт суулгалт яг аль орчинд очихыг тодорхой болгоно; Windows дээр Python executable-ийн зам өөр байна.

Хуучин CI-д хэрэглэсэн Python хувилбарыг uv venv --python сонголтоор давт. Өөр Python сонговол багцын боломжит хувилбар болон платформын wheel өөрчлөгдөж, зөрүүний шалтгааныг ялгахад хэцүү болно. uv pip нь идэвхтэй орчныг ашиглаж, идэвхтэй орчин байхгүй үед .venv-г хайдаг; харин uv-ийн төслийн горим .venv-г өөрөө удирддаг. Иймээс суулгах орчин, тест ажиллуулах орчин хоёрыг нэг болгож баталгаажуул.

Lockfile үүсгэхдээ resolver-ийн зөрүүг хар

pip-tools хэрэглэдэг бол pip-compile requirements.in -o requirements.txt алхмын шинэ хувилбарыг uv pip compile requirements.in -o requirements-uv.txt гэж тусдаа файлд ажиллуул. Хоёр файлын шууд болон шууд бус багцын хувилбаруудыг харьцуулж, өөрчлөгдсөн хувилбар бүрийг зориуд зөвшөөр. uv pip sync requirements-uv.txt нь жагсаалтад байхгүй багцыг орчноос хасдаг, мөн файлд ороогүй шууд бус хамаарлыг нөхөж суулгадаггүй. Тиймээс энэ командыг бүрэн гаргасан жагсаалт дээр хэрэглэж, тестэд хэрэгтэй хөгжүүлэлтийн багцуудыг орхигдуулаагүй эсэхийг шалга.

uv нь pip-ийн суулгаж болох зарим багцыг стандартын зөрчлөөс болж татгалзаж болно; жишээлбэл, индексийн HTML доторх буруу URL fragment асуудал үүсгэнэ. Алдаа гарвал requirements-ийн хязгаарыг шууд суллахын өмнө татгалзсан багц, хувилбар, индексийг тогтоо. Зассан багцын хувилбар байгаа бол түүнийг сонгоод гарсан өөрчлөлтийг түгжээний ялгаанд тэмдэглэ. Хувийн болон нийтийн индексэд ижил нэртэй багц байвал uv эхэлж олсон индексийн хувилбаруудаар сонголтоо хязгаарладаг тул индексийн дараалал ч үр дүнд нөлөөлнө.

Төслийн горимд шилжихэд uv-ийн шилжүүлэх заавар requirements.in-ийг uv add -r requirements.in -c requirements.txt командаар оруулж, хуучин түгжсэн хувилбаруудыг constraint болгон ашиглахыг зөвлөдөг. pyproject.toml байхгүй бол uv init-ээр үүсгэж, байгаа бол доторх төслийн тохиргоог хадгал. Үүссэн uv.lock-ийг хувилбарын удирдлагад оруул; платформ тус бүрт өөр requirements файлтай бол тэдгээрийн constraint-ийг универсал түгжээнд шууд нийлүүлэхэд зөрчил гарч болохыг тооц.

CI команд ба кэшийн түлхүүрийг соль

CI-д хуучин pip ажлыг хадгалаад uv ашиглах тусдаа ажлыг ижил Python хувилбар, ижил тестээр ажиллуул. Requirements дээр үлдвэл суулгах алхам нь uv pip install -r requirements.txt болно. uv.lock-д шилжсэний дараа uv sync --locked, дараа нь uv run --locked pytest зэрэг командыг хэрэглэж болно. --locked нь төслийн тодорхойлолт ба түгжээ зөрвөл CI явцад түгжээг шинэчлэхийн оронд алдаа өгөхөд хэрэгтэй.

GitHub Actions-д uv-ийн CI заавар astral-sh/setup-uv-ийн enable-cache тохиргоо, uv pip ашиглах үед requirements.txt, төслийн горимд uv.lock-ийг кэшийн түлхүүрт авах жишээг өгдөг. Эхлээд кэшгүй цэвэр ажиллуулж суулгалт давтагдахыг шалгаад дараа нь кэшийг асаа. Ажлын төгсгөлд uv cache prune --ci хэрэглэж болно; түүний хурданд үзүүлэх нөлөө суулгаж буй багцуудаас хамаарна.

CI болон Docker тохиргооноос pip-ийн бүх командыг хайж үз. uv pip нь pip-ийн бүх subcommand, сонголтыг хэрэгжүүлээгүй бөгөөд --user суулгалтыг дэмждэггүй. Ийм мөрийг үгчлэн солихын оронд virtual environment рүү суулгах байдлаар өөрчил. Үндсэн install алхам амжилттай болсон ч туслах команд дутсанаас publish, шалгалт эсвэл бусад CI ажил унаж болно.

Private registry-ийн тохиргоо, нэвтрэлтийг сэргээ

Хувийн индексийг pip.conf эсвэл PIP_INDEX_URL-ээр заасан бол uv тэдгээрийг автоматаар уншихгүй. uv pip ажлын урсгалд UV_INDEX_URL, uv.toml эсвэл pyproject.toml-ийн [tool.uv.pip] тохиргоогоор индексийг ил тод заа. Төслийн горимд индексийн тохиргоог pyproject.toml-д тусад нь тодорхойлж болно. pip багцыг олж байхад uv олж чадахгүй бол эхлээд индексийн хаяг шинэ ажилд үнэхээр дамжсаныг шалга.

keyring ашигладаг бол нэвтрэлтийг индексийн хаягаас тусад нь турш. uv keyring нэвтрэлтийг анхдагчаар асаадаггүй; pip-ийн auto болон import горимын оронд subprocess горимыг дэмждэг. Тохирох keyring команд суусан орчинд --keyring-provider subprocess сонголтыг ашиглаж болно. CI-ийн нууцыг түгжээний файлд бичихгүйгээр ажлын орчноор дамжуулж, хувийн багцыг цэвэр орчноос татаж чаддаг эсэхийг шалга.

Олон индекс хэрэглэдэг төсөлд хаяг зөв байгааг дангаар нь батлах хангалтгүй. uv багцын нэрийг эхэлж олсон индексээс хувилбар сонгодог тул хуучин pip ажлын урсгал өөр индексээс авдаг байсан багц солигдож болно. Суулгалтын дараа хувийн багцын нэр, хувилбар, татсан индексийг шалгаж, шаардлагатай бол багцыг тодорхой индекстэй холбосон тохиргоо хэрэглэ.

Bytecode-ийг шалгаад буцаах замаа хадгал

pip-ээс ялгаатай нь uv суулгах үед .py файлуудын .pyc bytecode-ийг анхдагчаар үүсгэдэггүй. Docker image-ийн эхлэх хугацаа чухал, эсвэл суулгалтын дараах бэлэн __pycache__-д ажлын урсгал тулгуурладаг бол uv pip install -r requirements.txt --compile-bytecode гэж турш. Бүрэн түгжсэн requirements файлтай үед uv pip sync requirements.txt --compile-bytecode мөн боломжтой. Энэ сонголт суулгах хугацааг нэмэгдүүлдэг тул тухайн ажлын урсгалын эхлэх ажиллагаанд хэрэгтэй эсэхээр шийд.

Шилжилтийг зөвшөөрөхөөс өмнө ижил Python хувилбарт багцууд суусан, хувийн индекст нэвтэрсэн, тест болон CI-ийн үндсэн ажил давсан эсэхийг шалга. Аль нэг алхам унавал uv-ээр өөрчилсөн орчныг нөхөж засахын оронд хадгалсан requirements файлаас цэвэр орчинд python -m pip install -r requirements.txt ажиллуулж, хуучин CI ажлыг сэргээ. Алдааны багц, команд, индексийн тохиргоог тэмдэглэвэл дараагийн uv туршилтад засах ёстой тодорхой зөрүү үлдэнэ.