Wsparcie Rusta / Cargo w #Gentoo otrzymało wiele optymalizacji.
Brzmi to jak coś dobrego, prawda? To nie to — Cargo jest tak *beznadziejne*, że musimy ciągle dodawać jakieś obejścia, żeby dało się go w ogóle używać.
Na początek, od razu zrezygnowaliśmy z tworzenia odrębnych paczek dla zależności. Wszak mówimy o tworzeniu tysięcy paczek, których jedyną funkcją byłoby instalowanie źródeł, które następnie byłyby statycznie włączane do programów. Kupa roboty, kupa zmarnowanej przestrzeni, i żadnej korzyści. Tak więc każda paczka Rusta zawiera w sobie długą listę swoich zależności, i gigantyczny plik Manifest z kolejną kopią tych samych sum kontrolnych.
Uzależnieni jesteśmy też od mirrorowania zależności na serwerach lustrzanych Gentoo. Dlaczego? Bo crates.io jest beznadziejnie powolne. Portage normalnie pobiera pliki jeden po drugim, więc pobranie setek zależności trwa wieczność. Nawet w #PyCargoEbuild dodałem wsparcie pobierania zależności równolegle przez aria2, żeby to przyspieszyć.
Niedawno dodałem wypakowywanie zależności równolegle, bo nawet to zajmowało mnóstwo czasu. Ironią jest, że najdłużej wypakowują się pliki odpowiedzialne za wsparcie Windows.
PyCargoEbuild ma też funkcję przepakowania wszystkich zależności w jedno archiwum. Dlaczego? Bo niektóre programy mają ich tak wiele, że wypisanie wszystkich czyni ebuilda olbrzymim, a powiązany z nim Manifest kolosalnym. Oznaczałoby to, że *każdy* użytkownik Gentoo obarczony byłby rosnącym repozytorium, nawet gdyby nigdy nie miałby użyć tej paczki. Zamiast pobierać zależności pojedynczo, bierzemy gotowe archiwum, które przy okazji jest mniejsze niż suma wszystkich zależności, pobiera i wypakowuje się dużo szybciej (choć nie porównywałem tego z wypakowywaniem równoległym).
W ogóle, czy nie powinienem zaznaczyć, że Cargo to jeden z niewielu ekosystemów, których nie da się wykorzystać w dystrybucji, nie tworząc wcześniej dedykowanego oprogramowania, które będzie tworzyć za nas ebuildy i je później aktualizować?
Ale nie, #RustLang just super.
