Biblioteki eclass związane z Pythonem w #Gentoo są całkiem aktualne. Stosują się do aktualnych zaleceń i standardów, i usuwają na bieżąco rzeczy przestarzałe. Niemniej, mają za sobą długą historię, i najlepiej chyba to widać po nazewnictwie.

Biblioteki te powstały w celu zastąpienia wcześniejszych "distutils" i "python". Dlatego też nazwałem je odpowiednio "distutils-r1" i "python-r1", podążając za schematem rewizji dla ebuildów. Dla spójności, pozostałe biblioteki również doczekały się sufiksu "-r1": "python-any-r1", "python-single-r1" i "python-utils-r1" — mimo że nigdy nie istniały w wersji "r0".

Wkrótce poznałem swój pierwszy błąd. Uczyniłem bibliotekę odpowiedzialną za budowanie paczek dla wielu implementacji "domyślną", prawdopodobnie w oparciu o ówczesne rekomendacje pisania ebuildów. Jednak z czasem odkryłem, że w większości przypadków (tam, gdzie nie używamy "distutils-r1") nie potrzeba takiej funkcjonalności, a ebuildy stają się niepotrzebne skomplikowane. Gdybym wybierał nazwy dzisiaj, najpewniej nazwałbym ją "python-multi", żeby podkreślić zastosowanie. A "domyślnej" albo by nie było w ogóle, albo byłaby nią "python-single".

Z "distutils-r1" jest jeszcze gorzej. Oczywiście, kiedy powstawała, distutils wciąż istniało, a niektórzy ludzie (jak ja) preferowali je nad zależnością od setuptools. A dziś zostało już całkiem pochłonięte przez setuptools, a za sprawą #PEP517 nawet "setuptools" nie jest już dobrą nazwą. No i ludzie dziwią się, że np. dla systemu budowania Hatchling mają używać "distutils-r1".

No i to już jest coś, co mogłem zrobić lepiej. Wprowadzenie wsparcia PEP517 była sporą zmianą, i zamiast dodawać zmienną DISTUTILS_USE_PEP517 (nazwa ze sprzecznością), mogłem utworzyć nową bibliotekę. Dlaczego tego nie zrobiłem? Cóż, jeden i drugi tryb dzieliły ze sobą sporo kodu, i nie było sensu go duplikować. Oczywiście, z czasem wspólnego kodu było trochę mniej, i w końcu wsparcie starego trybu wyleciało — ale to już po ptakach.

(1/2)