asdf-vm
2022-01-08
Wszyscy lubią dobry sequel, choć szansa na niego jest znikoma. W zeszłym tygodniu pisałem o wygodnej metodzie instalacji programów napisanych w Pythonie, a dziś przedstawię Wam podobne rozwiązanie: z tą różnicą, że nie „programów w Pythonie” tylko „wszystkiego w sumie z naciskiem na języki programowania i narzędzia pomocnicze”. asdf-vm
W „Boskiej Komedii” Alighieri opisuje 9 kręgów piekła do którego może trafić grzeszna dusza. Wbrew religijnej ikonografii ostatni krąg nie ma gotującej się siarki i diabołów uzbrojonych w ostre narzędzia rolnicze tylko jezioro skute na wieki lodem, najbardziej oddalone od ciepła bożej miłości. Gdybym miał talent (no, więcej talentu) napisałbym pastisz w którym na końcu byłby asdf instalujący Pythona, instalujący pipx, instalujący docker-compose, w kontenerze. Dziewięć kręgów abstrakcji, prawdziwe piekło.
Żarty na bok, ale w zasięgu ręki.
W przeciwieństwie do pipx, który używa standardowych mechanizmów Pythona, asdf to bardzo lekka specyfikacja do skryptów instalacyjno-kompilacyjnych zarządzana przez super-polecenie.
Podczas pisania tego tekstu dostępne są 4201 specyfikacje, które w nomenklaturze asdf nazywamy pluginami. Większość z nich dostarczona jest przez osoby zewnętrzne, więc standardowe ostrzeżenie o „odpalasz czyjeś skrypty z Internetu” obowiązuje każdego dnia i każdej nocy.
Co do jakości samych wtyczek: jest różnie. Niektóre budują oprogramowanie wprost ze źródeł, inne znów pobierają skompilowane binarki. Podobnie jak w świecie kontenerów istnieje założenie, że końcowy odbiorca posiada komputer z x64. W chwili obecnej takowego nie posiadam, niektóre instalatory popełniają więc naiwne błędy: ściągają binarkę na x64, kładą ją do wirtualnego katalogu, zacierają ręce i mówią — „gotowe”, czy trochę lepiej, wywracają się od razu na kolana mówiąc „nie ma takiej architektury — armhf”. Innymi słowy, jeśli upstream nie rozwiązał problemów wieloplatformowości są niewielkie szanse, że autor wtyczki do asdf poświęcił czas na testowanie instalacji na nie-Intelach.
Jedna funkcja samego asdf jest mi szczególnie miła. Poza możliwością instalowania obok siebie kilku wersji tego samego programu istnieje też możliwość zadeklarowania jaka wersja jest globalna (widziana przez powłokę normalnie) a jaka jest lokalna (na przykład w katalogu projektu).
Uratowało to moją duszę przed wizytą w drugim kręgu, gdy odziedziczyłem po frontendowcach projekt, który potrafił się tylko zbudować jedną konkretną wersją nodejs. Dlaczego? Nikt nie wiedział, a ostatnia osoba, która mogła coś na to poradzić postanowiła sprzedawać łódki dłubane w korze na rogach jasno-oświetlonych domów handlowych.
Wystarczy przenieść się do katalogu projektu i wydać polecenie asdf local nodejs 12.18.3 (oczywiście po wcześniejszym zainstalowaniu) i za każdym razem gdy odwiedzimy nasz projekt wersja zmienia się magicznie pod naszymi stopami. Wersję ustawia zawartość pliku .tool-version, możemy go wciągnąć do repozytorium, co pomaga ludziom tak zapominalskim jak ja.
Instalacja
Polecaną metodą jest sklonowanie repozytorium do katalogu domowego. Kilka pakietów, które próbowałem na Arch instalowały do /opt czy też /usr/local, nie pamiętam, w każdym razie kłóciło się nieco z moją ideą żeby wszystko żyło w katalogu domowym, dlatego usunąłem je i użyłem ręcznej metody.
git clone https://github.com/asdf-vm/asdf.git ~/.asdf --branch v0.8.1
Do skryptu uruchomieniowego powłoki należy dodać wywołanie ./$HOME/.asdf/asdf.sh rozpędzające machinerię. Jeśli używacie oh-my-zsh można dodać do jego konfiguracji plugins=(asdf git […]).
Używanie
Wpierw dobrze się rozejrzeć, co też dają w tej knajpie. Listę wszystkich dostępnych pluginów otrzymamy po wywołaniu:
asdf plugin list all
Jeśli nasza powłoka nie wspiera dopełnienia należy sprawdzić jakie wersje konkretnego pluginu możemy zainstalować:
asdf list all nodejs2
Obecnie doszedł uniwersalny tag latest aby ułatwić start. Niektóre pluginy zawierają też inne nazwy własne takie jak lts czy stable. Zainteresowani muszą zbadać sprawę na własną rękę.
Musimy dodać plugin do listy aktywnych:
asdf plugin add nodejs
By ostatecznie zainstalować rzecz samą w sobie. Dwie rzeczy na potrzeby demonstracji:
asdf install nodejs 12.18.3
asdf install nodejs latest
Kiedy (lub jeśli, build-essential + *-dev* będą nieodzowne) wybrany program się już zainstaluje możemy wybrać wersję do użycia. Domyślnie, bezpośrednio po instalacji, programy nie są aktywne.
asdf global nodejs 12.18.3 — wybierze nam domyślną wersję zainstalowanej aplikacji
asdf local nodejs latest — zadeklaruje wersję aplikacji do użycia w sytuacji, gdy znajdujemy się w danym katalogu.
W praniu
Poniższe wideo zawiera bardzo hipotetyczną sytuację.
Mam w Vimie wsparcie do fzf i chcę zainstalować program by móc z niej korzystać. Z jakiegoś powodu, być może na potrzeby demonstracji, ubzdurałem sobie, że chcę je zainstalować w wersji 0.22.0. Ta wersja ma gotową binarną dystrybucję, więc wszystko kończy się na pobieraniu do odpowiedniego katalogu.
Zadeklarowałem wersję 0.22.0 jako globalną i odpaliłem Vima. O nie, szelma, zostałem zdradzony, wtyczka do Vima potrzebuje nowszej wersji fzf. A ta nie ma binarnej dystrybucji. Na szczęście 0.29.0 buduje się używając go, nomen omen, zainstalowanego via asdf, i mogę zadeklarować tę wersję jako lokalną.
Przyznam, że znalezienie czegoś do demonstracji zajęło mi więcej czasu niż pisanie samego tekstu. Szrotowany powindowsowy „tablet” z mizernym Atomem nie jest idealną platformą do kompilowania LibreOffice i nagrywania z tego wideo.