
מחזיק Gentoo מזמין מחזיקי פרויקטי Python להפסיק את השימוש ב-uv-build כ-backend
מחזיק Gentoo מזמין מחזיקי חבילות Python להימנע משימוש ב-uv-build כ-backend. הוא מציין תלות גדולה ב-Rust, מהדורות תכופות ובעיות ניידות, ומדגיש שהטענה מתייחסת ל-backend עצמו ולא ל-uv או לכלים אחרים של Astral.
קריאה
מיכל גורני, מפתח ב-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 סיביות. עבור פלטפורמות שלא נתמכות בכלל, הוספה ותחזוקה של פלטפורמה חדשה נחשבות משימה שלמה, שעשויה לגרום לכאב רב בשינויי קוד.
טיעונים לטובת אלטרנטיבות
גורני מכיר בכך שיש שני טיעונים לטובת 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
SiTech — פיתוח אתרים בכוח ה-AI
אנחנו בונים אתרים מהירים ומודרניים ומשלבים AI בתהליכי עבודה אמיתיים. יש לכם פרויקט או שאלה? נשמח לעזור.