مشرف Python في Gentoo يطلب من مطوري المكتبات عدم استخدام uv-build كـ backend
نشر Michał Górny، أحد مشرفي Python في توزيعة Gentoo، في 12 أكتوبر 2026 طلبًا موجّهًا إلى مطوري المكتبات: ألا يستخدموا uv-build كـ build backend. ويكتب صراحة أن الاعتراض ليس على uv نفسها، فهي في رأيه أدوات جيدة وفريقها متعاون، بل على الـ backend وحده.
والفرق بين الاثنين هو أساس القصة. فمواصفة PEP 517 فصلت الـ backend، الذي يبني الحزمة، عن الـ frontend، الذي يستدعيه. لذلك يمكن استخدام uv كأداة مع backend آخر تمامًا، ويعمل الاثنان معًا بلا مشكلة. فاختيار uv-build ليس شرطًا لاستخدام uv.
ويعرض Górny التكلفة بالأرقام. فحجم الـ wheel الخاص بـ uv-build في الإصدار 0.13.0 بين 1.2 و1.5 ميجابايت بحسب المنصة، بينما حجم wheel الخاص بـ flit-core، وهو backend مكتوب بـ Python خالصة، 45 كيلوبايت. وuv-build مكتوب بـ Rust، والتوزيعات التي تبني من المصدر مضطرة لبنائه مع كل إصدار جديد، وقد صدرت منه 12 نسخة في الثلاثين يومًا السابقة للمقالة.
والمكسب في المقابل، كما يكتب، في حدود 100 ميلي ثانية في عملية تُنفَّذ نادرًا. فمقابل كل 100 ميلي ثانية في تثبيت إصدار واحد من مكتبة، سيقضي مستخدمو Gentoo ساعات في بناء إصدارات uv-build الجديدة واحدًا بعد آخر.
والجانب الأهم عنده هو قابلية النقل بين المعماريات. فـ Python تعمل في أي مكان يتوفر فيه مترجم C يعمل، بينما المنصات التي تدعمها Rust تتوسع ببطء، ويضرب مثلًا بمكتبة rustix::fs التي تتخطى معمارية SPARC. وأحيانًا يكون الملف التنفيذي كبيرًا إلى حد أن تنفد مساحة العناوين لدى سلسلة الأدوات، وملف الـ ebuild الخاص بـ uv في Gentoo يحمل حلّين التفافيين ليُبنى على أنظمة 32 bit.
ولا تذكر المقالة عدد المكتبات التي انتقلت إلى uv-build، بل تقول إنها نحو دستة حزم في Gentoo.