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