العودة
مشرف Gentoo يطالب مشاريع Python بالتوقف عن استخدام uv-build backend
SiTech AI Team2 دقيقة قراءة

مشرف Gentoo يطالب مشاريع Python بالتوقف عن استخدام uv-build backend

يطالب مطور Gentoo مشرفي حزم Python بالتخلي عن uv-build بوصفه backend للبناء، معللاً ذلك بالاعتماد الكبير على Rust، وكثرة الإصدارات، ومشاكل النقلية بين المنصات بدلاً من بدائل أصغر.

دعوة

نشر ميخال غورني، مطور Gentoo، دعوة يطلب فيها من مشرفي حزم Python عدم استخدام uv-build backend للبناء. ويؤكد أن النقد لا يستهدف uv نفسه ولا أدوات Astral الأخرى، التي يصفها بأنها جيدة وتتمتع بوجود upstream جيد ومسؤول. المشكلة تحديداً في backend الخاص بـ uv-build، الذي لا تغطي فائدته عيوبه عند downstream توزيعات مثل Gentoo. ويشير إلى أن عشرات حزم Gentoo فقدت keywords مرة واحدة لأن اعتماداً أساسياً انتقل إلى uv-build.

الحجم وحمل البناء

المشكلة الأساسية أن uv-build كبير ومكتوب بـ Rust. في الإصدار 0.13.0 تتراوح ملفات wheel بين 1,2 MiB و1,5 MiB حسب المنصة، بينما مؤشر flit-core، backend نقي صغير مكتوب بـ Python، نحو 45 KiB فقط. ولأن Gentoo يبني الحزم من المصدر، يجب على كل مستخدم تجميع uv-build، بينما يصدر المشروع إصدارات جديدة بكثرة: قبل كتابة المقالة بـ 30 يوماً صدر 12 إصداراً. ويقدر غورني أن كل 100 ms يستغرقها تشغيل uv-build لتثبيت إصدار من حزمة، تنفقها قاعدة Gentoo من المستخدمين مجتمعة في ساعات لإعادة بناء إصدارات uv-build الجديدة مراراً.

مشاكل النقلية

يقول غورني أن وقت البناء ليس أكبر مشكلة، بل النقلية. يمكن أن يعمل Python تقريباً في كل مكان يوجد فيه مترجم C للعمل، بينما قائمة المنصات المدعومة بـ Rust تنمو ببطء. وحتى عندما يتوفر مترجم Rust، قد لا يعمل uv بسبب مشاكل مختلفة: أخطاء في الاعتماديات، مثل rustix::fs وتجاهل SPARC من اعتمادياته، وصولاً إلى ملفات تنفيذية كبيرة بحيث لا تسع مساحة toolchain العناوين. وتحتوي ebuild الخاصة بـ uv في Gentoo بالفعل على اثنين من الحيل لبناء uv على منصات 32-bit. وبالنسبة للمنصات غير المدعومة أصلاً، تُحسب إضافة منصة جديدة والحفاظ عليها قسماً مستقلاً، وقد يتضمن ذلك تغييرات كثيرة في الشفرة.

حجج لصالح البدائل

يعترف غورني بوجود حتين لصالح uv-build. الأولى هي الاتساق مع استخدام uv داخل المشروع، وهو ما يرفضه، لأن PEP 517 يعني أن أي backend يعمل مع أي frontend، لذلك سيعمل flit-core أو hatchling دون مشكلة مع uv أو أي أداة أخرى. والثانية هي الكفاءة، التي يقول إنها تبلغ نحو 100 ms لعملية نادرة التنفيذ، ويمكن أن يغطيها أيضاً الوقت اللازم لتنزيل wheel بحجم 1,5 MiB. ويختم بأن الـ backend يستخدمه مطورو المشروع ومساهموه وسير عمل CI/CD ومنشئو حزم downstream ومستخدمو توزيعات المصدر، بينما يستخدم المستخدمون العاديون wheel فقط. ومن بين هذه المجموعات، مستخدمو توزيعات المصدر هم الأكبر والأكثر تضرراً، وأي كسب في الكفاءة يضيع في الوقت المصروف على بناء uv-build.

المصادر: Lobsters

SSiTech

SiTech — تطوير ويب مدعوم بالذكاء الاصطناعي

نبني مواقع سريعة وعصرية وندمج الذكاء الاصطناعي في سير عمل الشركات. لديك مشروع أو سؤال؟ يسعدنا مساعدتك.