uv وRuff: كيف ابتلعت أداتان سلسلة أدوات بايثون كاملة في 2026؟

لو فتحت مشروع بايثون كُتب عام 2022 اليوم، ستجد في جذره طبقة كاملة من الأدوات: pyenv لإدارة إصدارات المفسّر، وvenv للبيئة الافتراضية، وpip للتثبيت، وpip-tools أو poetry لتثبيت الإصدارات، وblack للتنسيق، وisort لترتيب الاستيرادات، وflake8 للفحص، وpyupgrade للتحديث. ثمانية أدوات، ثمانية ملفات إعدادات، وثمانية مشاريع قد يتوقف أيّ منها عن التطوّر في أي لحظة.

في 2026 صار الجواب المعتاد على هذه القائمة كلها أداتين: uv وRuff. كلاهما مكتوب بلغة Rust، وكلاهما أسرع بما يكفي ليغيّر سلوكك لا وقتك فقط. لكن القصة الأهم هذا العام ليست السرعة — بل من صار يملك هذه الأدوات.

ما الذي حدث فعلاً؟

التحوّل لم يكن إعلاناً واحداً بل تراكماً استمرّ ثلاث سنوات، بلغ نقطة الحسم في 2026:

• uv ابتلع وظائف pip وvenv وpyenv وpoetry في ملفّ تنفيذي واحد: يدير إصدارات بايثون نفسها، وينشئ البيئات، ويحلّ التبعيات، ويولّد ملف قفل، ويبني الحزمة وينشرها.
• Ruff ابتلع flake8 وblack وisort وpyupgrade: فاحص ومنسّق في أداة واحدة، بقواعد تغطّي مئات الفحوص التي كانت موزّعة على إضافات متفرّقة.
• ty انضمّ حديثاً إلى ساحة فحص الأنواع إلى جانب mypy وpyright، وهي الساحة الوحيدة التي لم تُحسم بعد.

وفي فبراير 2026 أُرشِف مشروع Rye — وكان أحد أبرز محاولات التوحيد السابقة — وقُرئ ذلك على نطاق واسع بوصفه نهاية مرحلة التشظّي. الأرقام تدعم القراءة: تنزيلات uv الشهرية من PyPI تجاوزت 126 مليوناً مقابل نحو 75 مليوناً لـPoetry، ومشاريع بحجم Pandas وFastAPI وHugging Face وApache Airflow انتقلت إليه رسمياً.

لماذا Rust تحديداً؟

ليس لأن Rust «لغة موضة»، بل لأن مشكلة أدوات بايثون كانت بنيوية: أداة مكتوبة ببايثون تحتاج مفسّر بايثون لتعمل، وتحتاج بيئة، وتحتاج تبعياتها الخاصة التي قد تتعارض مع تبعيات مشروعك. الأداة المُصرَّفة إلى ملف تنفيذي واحد تكسر هذه الحلقة: تنزّلها وتشغّلها قبل أن يكون هناك بايثون على الجهاز أصلاً.

النتيجة العملية أن عمليات كانت تستغرق دقائق صارت تستغرق ثواني. وهذا ليس ترفاً: منصّة Codex في OpenAI انتقلت داخلياً من pip إلى uv، والرقم الذي ذُكر لتبرير القرار كان توفير ما يقارب مليون دقيقة حوسبة أسبوعياً.

السرعة حين تتجاوز عتبة معيّنة تتوقّف عن كونها راحة وتصير تغييراً في السلوك. البيئة التي تُبنى في ثانيتين تُحذَف وتُعاد من الصفر بلا تردّد؛ والبيئة التي تحتاج ثلاث دقائق تُرقَّع لسنوات.

الجانب الذي يقلّ الحديث عنه: من يملك البنية التحتية؟

هنا يتغيّر مزاج القصة. في مارس 2026 استحوذت OpenAI على شركة Astral، الشركة التي تطوّر uv وRuff وty. أي أن سلسلة أدوات بايثون التي توحّدت للتوّ صار يملك الجزء الأكبر منها لاعب واحد، ولاعب ليس تاريخه في البنية التحتية للغات البرمجة.

من الإنصاف قول الوجهين:

الحجّة	مضمونها
المطمئنة	الأدوات مفتوحة المصدر برخص متساهلة، ويمكن اشتقاقها في أي لحظة؛ والتمويل المستقر يحلّ مشكلة الصيانة المزمنة
المقلقة	التركّز في جهة واحدة يجعل قرار توجيه الأداة قراراً تجارياً لا مجتمعياً؛ والاشتقاق سهل نظرياً وباهظ عملياً

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

في المقابل، تحرّك المجتمع في اتجاه موازن: صار لمجال التغليف مجلس منتخَب من خمسة أعضاء بصلاحيات تقارب مجلس التوجيه، بدل التنسيق غير الرسمي الذي دام سنوات. هذه خطوة تفصل حوكمة المعايير عن حوكمة الأدوات — وهو بالضبط الفصل الذي يحدّ من أثر أي مالك منفرد.

ميزات أمنية تستحق أن تعرفها

بمعزل عن نقاش الملكية، أضافت الأداة خلال 2026 ميزتين عمليتين يغفل عنهما كثيرون:

• uv audit لفحص تبعيات مشروعك بحثاً عن ثغرات معروفة، مع كشف تجريبي للحزم الخبيثة يمنع تثبيت ما هو معروف بسوئه.
• فترة التهدئة عبر إعداد مثل exclude-newer = "7 days"، ومعناه: ارفض أي حزمة نُشرت خلال آخر سبعة أيام.

الميزة الثانية تستحق وقفة لأنها تعاكس الحدس. نحن معتادون على أن «الأحدث أفضل»، بينما أغلب هجمات سلسلة التوريد تُكتشف وتُزال خلال ساعات أو أيام من نشرها. تأخير التبنّي أسبوعاً واحداً لا يكلّفك شيئاً تقريباً، ويُخرجك من النافذة الزمنية التي تقع فيها غالبية الإصابات. هذا دفاع بالوقت لا بالتحليل، وهو رخيص إلى حدّ يجعل عدم تفعيله غريباً.

هل يجب أن تهاجر؟ الجواب الأقلّ إثارة هو الصحيح

النصيحة السائدة بين من جرّبوا فعلاً معتدلة أكثر مما توحي به العناوين:

1. مشروع جديد؟ ابدأ بـuv مباشرة. لا يوجد سبب وجيه لبدء مشروع في 2026 بسلسلة الأدوات القديمة.
2. مشروع قائم على Poetry ويعمل؟ اتركه. الهجرة تكلّف وقت فريق وتراجع خطوط بناء، ولا تُبرَّر إلا بألم محدّد تشعر به فعلاً — بناء بطيء في التكامل المستمر، أو حلّ تبعيات يستغرق دقائق.
3. ابدأ بـRuff قبل uv إن أردت مكسباً سريعاً. استبداله بـflake8+black+isort تغيير محصور في ملف الإعدادات وخطوة الفحص، ولا يمسّ طريقة بناء المشروع ولا نشره.
4. في التكامل المستمر، الفارق أكبر مما تتوقّع. أغلب المكسب الحقيقي يظهر هناك لا على جهازك: تثبيت التبعيات في كل تشغيلة هو ما كان يلتهم الدقائق.
5. ثبّت إصدار الأداة نفسها في خط البناء. أداة تتطوّر بسرعة تعني أن ترقية غير مقصودة قد تغيّر سلوك الفحص. ثبّت، ثم رقِّ عن قصد.
6. فعّل فترة التهدئة وuv audit من اليوم الأول. خطوتان في الإعدادات، ومكسب أمني غير متناسب مع كلفتهما.

وماذا عن pip؟

لم يمت ولن يموت قريباً. هو جزء من بايثون نفسها، ويعمل بثبات، وموجود في كل بيئة تقريباً. السيناريو الأرجح ليس اختفاءه بل انزواؤه إلى دور الطبقة الأساسية التي تُستدعى نادراً بشكل مباشر — تماماً كما لا يستدعي معظم المطوّرين المُجمِّع يدوياً وهم يستخدمون أدوات البناء الحديثة.

أسئلة شائعة

هل أخسر توافقي مع بقيّة النظام البيئي إن انتقلت إلى uv؟ لا في الحالة الشائعة. uv يعمل على ملف pyproject.toml المعياري ويتعامل مع حزم PyPI العادية، ويستطيع قراءة ملفات requirements.txt وتوليدها. نقطة الاحتكاك الوحيدة المعتادة هي ملف القفل الخاص به، وهو تفصيل داخلي لفريقك لا يراه مستهلكو حزمتك.

هل استحواذ شركة على أدوات مفتوحة المصدر يعني أنها قد تُغلَق غداً؟ الكود المنشور برخصة متساهلة لا يمكن سحبه بأثر رجعي؛ ما يمكن تغييره هو اتجاه التطوير المستقبلي ورخصة الإصدارات القادمة. الخطر الواقعي إذاً ليس «إغلاقاً مفاجئاً» بل انحرافاً تدريجياً في الأولويات. وهذا يُدار بالمتابعة لا بالقلق: راقب إعلانات الترخيص، وأبقِ مشروعك متوافقاً مع المعايير لا مع أداة بعينها.

Ruff يحلّ محلّ الفاحص والمنسّق معاً — ألا يخالف ذلك مبدأ «أداة واحدة لمهمّة واحدة»؟ يخالفه شكلاً، ويخدم المستخدم مضموناً. المبدأ نشأ لتجنّب الأدوات الضخمة الجامدة، لا لتبرير ثمانية ملفات إعدادات لمهمّة واحدة هي «حافظ على نظافة الكود». الميزان العملي هنا: هل تستطيع إزالة الأداة والعودة بلا ألم؟ مع Ruff نعم، لأن قواعده تقابل أدوات معروفة ومخرجاته قياسية.

الخلاصة

ما حدث في سلسلة أدوات بايثون خلال 2026 ليس ترقية أدوات — هو إعادة رسم لخريطة كاملة. ثمانية مشاريع تقلّصت إلى اثنين، ومئات الثواني في كل خط بناء صارت عشرات، وتشظٍّ دام عقداً انتهى إلى توحيد فعلي.

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