Gentoo geliştiricisi Python projelerini uv-build'i backend olarak kullanmayı bırakmaya çağırıyor

Çağrı

Michal Gurny, Gentoo geliştiricisi, Python paket sorumlularından build backend olarak uv-build kullanmayı bırakmalarını isteyen bir çağrı yayınladı. Eleştirinin kendisini (uv) veya Astral'ın, iyi araçlar olarak nitelendirdiği ve iyi, sorumlu bir upstream'a sahip diğer araçları ilgilendirmediğini vurguluyor. Ona göre sorun özellikle uv-build backend'indedir ki, faydası Gentoo gibi downstream dağıtımlar için dezavantajlarını aşmaktadır. Bir ana bağımlılığın uv-build'e geçmesi nedeniyle yüzlerce Gentoo paketinin keywords kaybettiğini belirtiyor.

Boyut ve Derleme Yükü

Ana sorun, uv-build'in büyük ve Rust ile yazılmış olması. 0.13.0 sürümü için wheel'leri platforma göre 1,2 MiB ile 1,5 MiB arasında değişirken, küçük temiz Python backend'i flit-core'in boyutu yaklaşık 45 KiB'dir. Gentoo paketleri kaynaktan derlediğinden, her kullanıcının uv-build'i derlemesi gerekir, ancak proje oldukça sık yeni sürümler yayınlıyor: makalenin yazılmasına 30 gün kala 12 sürüm yayınlanmıştı. Gurny, bir paket sürümünü kurmak için uv-build'in çalıştırması gereken her 100 ms'de, Gentoo kullanıcılarının toplu olarak yeni uv-build sürümlerini tekrar tekrar derlemek için saatlerce harcadığını değerlendiriyor.

Taşınabilirlik Sorunları

Gurny, derleme zamanının en büyük sorun olmadığını, asıl sorunun taşınabilirlik olduğunu söylüyor. Python, çalışan bir C derleyicisinin bulunduğu neredeyse her yerde çalışabilirken, Rust tarafından desteklenen platformların listesi yavaş yavaş büyüyor. Rust derleyicisi mevcut olsa bile, uv çeşitli sorunlar nedeniyle çalışmayabilir: bağımlılıklardaki hatalar, örneğin rustix::fs ve bağımlılıklarının SPARC'ı atlaması, toolchain'in adres alanına sığmayacak kadar büyük çalıştırılabilir dosyalara kadar. Gentoo'nun uv ebuild'inde zaten uv'yi 32-bit platformlarda derlemek için iki hack var. Hiç desteklenmeyen platformlar için, yeni bir platform eklemek ve sürdürmek tam zamanlı bir iş olarak kabul edilir ve bu, kod değişikliklerine bağlı birçok çekme talebi içerebilir.

Alternatifler İçin Argümanlar

Gurny, uv-build yerine kullanılması için iki argüman olduğunu kabul ediyor. Biri, projedeki uv ile uyumluluk, ancak PEP 517'nin her backend'in herhangi bir frontend ile çalıştığını belirttiğinden bunu reddediyor; bu nedenle flit-core veya hatchling uv veya başka herhangi bir araçla sorunsuz çalışır. İkincisi ise performans; ona göre nadiren gerçekleştirilen bir işlem için yaklaşık 100 ms'yi oluşturur ve bu, 1,5 MiB'lik bir wheel'i indirmek için gereken zamanla karşılaştırılabilir olabilir. O, backend'in yalnızca proje geliştiricileri, katkıcılar, CI/CD iş akışları, downstream paket oluşturucuları ve kaynak dağıtımı kullanıcıları tarafından kullanıldığını, buna karşılık sıradan kullanıcıların wheel kullandığını belirtiyor. Bu gruplardan kaynak dağıtımı kullanıcıları en büyük ve en çok etkilenen gruptur ve herhangi bir performans kazancı, uv-build derlemesinde harcanan zamanda kaybolur.

Kaynaklar: Lobsters