Gentoo-ի պահառումը Python-ի րոեկտներին կոչ է անում դադարեցնել uv-build-ի օգտագործումը որպես կառուցման բեքենդ

Կոչ

Միխալ Գուրնին, Gentoo-ի պահառումը, հրապարակել է կոչ, որում Python-ի րոեկտների պահառումներին խնդրում է չօգտագործել uv-build-ը որպես կառուցման բեքենդ: Նա ընդգծում է, որ քննադատությունը վերաբերում չէ հենց uv-ին կամ Astral-ի այլ գործիքներին, որոնք նա նկարագրում է որպես լավ գործիքներ, բարի և պատասխանատու upstream-ով: Նրա կարծիքով, խնդիրը հատուկ uv-build-ի բեքենդն է, որի առավելությունը չի գերազանցում դրա թերությունները այդպիսի downstream դիստրիբյուտորների համար, ինչպիսին է Gentoo-ն: Նա նշում է, որ արդեն տասնյակ Gentoo-ի րոեկտ կորցրել է keywords-ը, քանի որ մեկ հիմնական կախվածությունը անցել է uv-build-ի վրա:

Չափը և կառուցման բեռը

Հիմնական խնդիրն այն է, որ uv-build-ը մեծ է և գրված է Rust-ով: 0.13.0 տարբերակի համար դրա wheel-երը ըստ պլատֆորմի տատանվում են 1,2 MiB-ից 1,5 MiB, մինչդեռ flit-core-ին, փոքր մաքուր Python-ի բեքենդին, մոտավորապես 45 KiB է: Քանի որ Gentoo-ն փաթեթները կառուցում է աղբյուրից, յուրաքանչյուր օգտատերը պետք է հավաքում է uv-build-ը, իսկ նախագիծը բավականին հաճախ է թողարկում նոր տարբերակներ: Հոդվածը գրելուց 30 օր առաջ 12 թողարկում էր: Գուրնին գնահատում է, որ յուրաքանչյուր 100 ms-ի համար, որը պահանջվում է uv-build-ի գործարկման համար փաթեթի մեկ թողարկման տեղադրման համար, Gentoo-ի օգտատերերը միասին շատ ժամ են ծախսում նոր uv-build տարբերակների կրկնակի կառուցման վրա:

Տեղափոխելիության խնդիրներ

Գուրնին հայտնում է, որ կառուցման ժամանակը մեծագույն խնդիրը չէ, հիմնականը տեղափոխելիությունն է: Python-ը կարող է աշխատել գրեթե ամենուրեք, որտեղ առկա է աշխատանքային C կոմպիլյատոր, մինչդեռ Rust-ի կողմից աջակցվող պլատֆորմների ցուցակը դանդաղ աճում է: Նույնիսկ երբ Rust-ի կոմպիլյատորը հասանելի է, uv-ն կարող է չաշխատել տարբեր խնդիրների պատճառով: Կախվածություններում առկա սխալներից, օրինակ rustix::fs-ի և դրա կախվածությունների կողմից SPARC-ի բաց թողնելուց, այնքան մեծ կատարողական ֆայլերի համար, որ toolchain-ը չունի հասցեների տարածք: Gentoo-ի uv ebuild-ն արդեն ունի երկու հակ, որպեսզի uv-ն կառուցվի 32-բիթային պլատֆորմների վրա: Պլատֆորմների համար, որոնք ընդհանրապես աջակցված չեն, նոր պլատֆորմի ավելացումը և պահպանումը լիովին համարվում է մասնագիտացված, ինչը կարող է ներառել շատ տեղումների փոփոխությունների կոդի վրա:

Արգումենտներ այլընտրանքների օգտագործման համար

Գուրնիը ճանաչում է, որ uv-build-ի օգտագործման համար երկու արգումենտ կա: Առաջինը նախագծում uv-ի օգտագործման հետ համատեղելիությունն է, որը նա մերժում է, քանի որ PEP 517-ը նշանակում է, որ ցանկացած բեքենդ աշխատում է ցանկացած frontend-ի հետ, ուստի flit-core-ն կամ hatchling-ը անխնդիրորեն աշխատում է uv-ի կամ ցանկացած այլ գործիքի հետ: Երկրորդը արդյունավետությունն է, որը ըստ նրա մոտավորապես 100 ms է հազվադեպ կատարվող գործողության համար և կարող է նույնիսկ ծածկել 1,5 MiB wheel-ի ներբեռնման համար անհրաժեշտ ժամանակը: Նա եզրակացնում է, որ բեքենդը օգտագործում են միայն նախագծի մշակողները, ներդրողները, CI/CD աշխատանքային հոսքերը, downstream փաթեթների ստեղծողները և աղբյուր դիստրիբյուտորների օգտատերերը, իսկ բոլոր սովորական օգտատերերը օգտագործում են wheel-եր: Այդ խմբերից աղբյուր դիստրիբյուտորների օգտատերերը ամենամեծն են և ամենավնասվածը, և ցանկացած արդյունավետության առավելությունը կորստվում է uv-build-ի կառուցման վրա ծախսված ժամանակում:

Աղբյուրներ: Lobsters