أداة uv لإدارة حزم بايثون: دليل عملي للانتقال من pip وvenv

بقلم فريق تقني ·3 يوليو 2026· أدوات المطورين

إذا كان يومك يبدأ بإنشاء بيئة افتراضية عبر venv، ثم تثبيت الحزم بـ pip، ثم تجميدها في requirements.txt، فهذه الخطوات الثلاث صارت تُختصر في أمر واحد. غير أن اختزال uv الرائج في صفة «بديل أسرع لـ pip» يظلمها: فالأداة تتولى الحزم والبيئات وإصدارات بايثون نفسها من واجهة واحدة. يجيب هذا الدليل عن خمسة أسئلة عملية: ما هي uv؟ من أين تأتي سرعتها؟ كيف تدير بها مشروعاً كاملاً؟ كيف ترحّل مشروعك القائم؟ ومتى يبقى pip خياراً معقولاً؟

هذا المقال امتداد عملي لمقالات قسم أدوات المطورين عن بايثون الحديثة؛ إن أردت الصورة الكاملة قبل الترحيل، ابدأ من أدوات بايثون الحديثة: دليل uv وRuff وpyproject.toml.

ما هي uv؟

uv مدير حزم ومشاريع لبايثون مكتوب بلغة Rust، تطوّره شركة Astral صاحبة أداة الفحص الشهيرة Ruff. أُعلنت في 15 فبراير 2024 برؤية صريحة: «Cargo لبايثون». المعنى العملي لهذا الشعار: بدل أن يثبّت pip الحزم، وتقفل pip-tools الإصدارات، وتعزل virtualenv البيئات، وتبدّل pyenv إصدارات المفسّر، وتشغّل pipx أدوات سطر الأوامر، وتحاول Poetry جمع بعض ذلك — أداة واحدة تغطي الوظائف الست.

بعد عامين ونصف، صار للرهان أرقام يُحاكم بها: نحو 160.7 مليون تحميل شهري على PyPI (بقياس 3 يوليو 2026)، وقرابة 87 ألف نجمة على GitHub. أحدث إصدار مستقر هو 0.11.26 بتاريخ 30 يونيو 2026 — أي أن الأداة، على كل هذا الانتشار، لم تبلغ بعد عتبة 1.0. وفي 19 مارس 2026 أعلنت OpenAI استحواذها على Astral، مع تعهد معلن بمواصلة دعم منتجاتها مفتوحة المصدر ودمج فريقها في فريق Codex.

وتنبيه سريع في التسمية قبل المتابعة: لا صلة لـ uv بمكتبتي uvicorn وuvloop رغم تشابه الأسماء.

من أين تأتي السرعة؟

الرقم الذي ستصادفه في كل مكان هو الادعاء الرسمي العام: أسرع من pip بـ 10-100 مرة. التفصيل أدق وأنفع. دون كاش تتراوح السرعة بين 8 و10 مرات، ومع كاش دافئ تقفز إلى 80-115 مرة، بينما إنشاء البيئة الافتراضية أسرع بنحو 80 مرة من python -m venv. والخطأ الشائع تقديم 100x وكأنه متوسط عام، بينما هو رقم الكاش الدافئ حصراً.

وراء هذه الأرقام عاملان: تنزيل الحزم بالتوازي، وكاش عالمي يعتمد الروابط الصلبة بدل نسخ الحزمة نفسها داخل كل بيئة على حدة. عملياً، عشرة مشاريع على جهازك تعتمد الحزمة ذاتها تتقاسم نسخة فعلية واحدة على القرص، فالتثبيت الثاني والعاشر لا يعيد التنزيل ولا يضاعف المساحة. ونقطة يخطئ فيها كثيرون: uv ليست غلافاً حول pip، بل تنفيذ مستقل بالكامل لا يستدعي pip داخلياً.

التثبيت

أسلم طريقة هي مدير الحزم الذي تعتمده أصلاً. على ماك:

brew install uv

على ويندوز:

winget install --id=astral-sh.uv -e

وعلى أي نظام مثبّت عليه بايثون:

pip install uv

ويوفر التوثيق الرسمي على docs.astral.sh/uv مثبّتاً مستقلاً عبر سكربت؛ إن فضّلته فنزّل السكربت أولاً وراجع محتواه قبل تنفيذه بدل تمريره إلى الصدفة مباشرة، وسيتاح لك حينها التحديث بأمر uv self update.

مشروع كامل بأوامر معدودة

ابدأ مشروعاً جديداً:

uv init hello-world

يولّد هذا الأمر pyproject.toml و.python-version وmain.py وREADME.md و.gitignore، وعند تنفيذ أول أمر يُنشأ مجلد .venv/ وملف القفل uv.lock تلقائياً. إدارة الاعتماديات مباشرة:

uv add requests
uv add 'requests==2.31.0'
uv remove requests
uv lock --upgrade-package requests

ثم التشغيل:

uv run main.py

لاحظ ما لم تفعله: لم تُفعّل .venv يدوياً قبل التشغيل. فـ uv run يتحقق تلقائياً من تطابق ملف القفل مع البيئة قبل تنفيذ الكود، وبذلك يغلق ثغرة مألوفة في العمل الجماعي: زميل أضاف اعتمادية، وسحبتَ تغييره دون إعادة تثبيت، فيعمل الكود عنده وينهار عندك. وعند سحب المشروع على جهاز جديد يكفي uv sync لبناء البيئة مطابقة للقفل.

إصدارات بايثون والسكربتات والأدوات

تغني uv عن pyenv في إدارة إصدارات بايثون نفسها:

uv python install 3.12
uv python list
uv python pin

وللسكربتات المفردة خارج أي مشروع، يمكن تمرير اعتمادية مؤقتة:

uv run --with rich example.py

أو تثبيت الاعتماديات داخل السكربت نفسه ثم تشغيله:

uv add --script example.py 'requests<3' 'rich'
uv run example.py

أما بديل pipx لتشغيل أدوات سطر الأوامر فهو uvx ruff وما شابهه.

الترحيل من requirements.txt

الخطوة الأولى uv init لتوليد pyproject.toml داخل مشروعك القائم. ثم الاستيراد الموصى به، وهو الذي يحافظ على الإصدارات المثبتة حالياً:

uv add -r requirements.in -c requirements.txt

ولاعتماديات التطوير:

uv add --dev -r requirements-dev.in -c requirements-dev.txt

احذر الاختصار المغري هنا. تنفيذ uv add -r requirements.txt مباشرة دون خيار -c قد يرقّي الإصدارات إلى أحدث ما هو متاح، وليس هذا ما تريده في مشروع إنتاجي. تحقق بعد الترحيل بتشغيل uv run pytest ثم uv sync.

والفارق بين الملفين أعمق من الصيغة: uv.lock ملف قفل عالمي يغطي كل المنصات، فالقفل نفسه يصلح لزميل يطوّر على ويندوز وخادم CI يبني على لينكس، بينما requirements.txt مرتبط بالبيئة التي جُمّد فيها. وإن احتجت إلى الصيغة القديمة لأنظمة لا تفهم غيرها، فالتصدير العكسي متاح: uv export --format requirements.txt.

متى يبقى pip كافياً؟

توفر uv واجهة متوافقة كبديل مباشر: uv pip install وuv pip compile وuv pip sync. لكن التوافق ليس مطابقة حرفية، والفروق موثقة: uv تثبّت في بيئة افتراضية افتراضياً وتتطلب --system للتثبيت في بايثون النظام، ولا تقرأ pip.conf ولا متغيرات PIP_* (بل UV_* وملف uv.toml)، ولا تدعم خيار --user.

لهذا يبقى pip خياراً منطقياً في حالات محددة. البيئات المؤسسية المبنية على pip.conf وسلوك pip الحرفي ستدفع ثمن الترحيل أكثر مما تكسب. والسكربتات البسيطة والبيئات التعليمية تستفيد من كون pip مدمجاً مع بايثون منذ الإصدار 3.4 عبر ensurepip، فلا يحتاج المتعلم إلى تثبيت شيء قبل درسه الأول. ومن يتحفظ على مستقبل الأداة بعد استحواذ OpenAI فله وجاهة في التريث، خصوصاً أن uv ما تزال في مرحلة 0.x دون التزام معلن بثبات كامل للواجهة.

يبقى القرار العملي بسيطاً: مشروع جديد أو فريق يعاني بطء بناء البيئات في CI؟ ابدأ بـ uv اليوم. بنية مؤسسية متجذرة حول pip أو سياق تعليمي؟ pip يؤدي عمله، وبوابة الترحيل ستبقى مفتوحة متى جهزت.