Béton brut

Moje komputerowe życie umila zaskakująca liczba programów napisanych w Pythonie. Na przykład wspominany wcześniej catt, bardzo wygodne i praktyczne klienty do baz danych jak pgcli czy mycli. Niezastąpiony youtube-dl (a właściwie jego fork yt-dlp) pozwalający archwizować media, goobook integrującym książkę kontaktową Googla z muttem. Mógłbym tak wymieniać długo.

Programy w Pythonie pisze się niezwykle przyjemnie, prawdziwe schody zaczynają się w momencie dystrybucji efektu naszej pracy. Część chce się instalować przez curl | sh, inne znów posiadają własne instalery i metody aktualizacji, są też oderwane od rzeczywistości pakiety .deb i .rpm niesiące ze sobą obietnice katastrofalnego zakłopotania systemu.

Jeśli deweloperzy dystrybucji (lub ludzie tworzący „hobbistyczne” repozyoria przylgnięte do oficjalnych (AUR czy PPA)) nie przygotowali gotowego pakietu końcowy użytkownik jest pozostawiony samemu sobie.

Niewprawiony użytkownik może sobie szybko skomplikować życie instalując rzeczy bezpośrednio w trzewia systemu. Zaawansowany użytkownik może się szybko znudzić żonglowaniem pół-rozwiązaniami wymyślonymi na szybko, które trochę działają, trochę nie.¹

Któregoś dnia „wdepnąłem” w pipx, program tworzący wirtualne środowiska per program jednocześnie zajmując się podlinkowaniem wykonywalnego skryptu. Dzięki temu możemy zainstalować wiele pożytecznych aplikacji bezpośrednio z PyPI bez większego bólu głowy, uzyskać dostęp do aktualizacji i możliwości usunięcia programu z systemu bez pozostawiania tradycyjnego kurzu i gruzu.

Instalacja

Użytkownicy bardziej konserwatywnych dystrybucji, więc i ja, nie mogą oczekiwać, że pipx będzie znajdował się w repozytorium. Znaczy to, że program przyjdzie nam zainstalować bezpośrednio z PyPI. Trzeba przyznać, że stajemy wtedy przed ciekawym problemem typu „jajko czy kura”. Dylemat ten pozostawię do rozważenia w Waszych sercach, osobiście proponuję pip3 install --user pipx i sprawdzenie, czy ~/.local/bin znajduje się w ścieżce (zmienna środowiskowa PATH).

Po instalacji możemy przetestować, czy wszystko poszło gładko wpisując pipx --version. Jeśli otrzymaliśmy numer wersji w odpowiedzi jesteśmy gotowi.

Używanie

Odpalenie pipx bez parametrów wyświetli nam listę dostępnych opcji. Część z nich tłumaczy się sama przez się, inne wymagają słowa objaśnienie.

Instalacja pakietu z PyPI:

pipx install yt-dlp

Instalacja pakietu bezpośrednio z repozytorium:

pipx install git+https://git.sr.ht/~bronikowski/pyswatch²

Usunięcie zainstalowanego pakietu:

pipx uninstall yt-dlp

Aktualizacja pakiet(ów):

pipx upgrade-all lub pipx upgrade yt-dlp dla ludzi o sercach miękkich wobec procesorów.

Uzyskanie listy już zainstalowanych pakietów:

pipx list

Przytrafiają się sytuacje, gdy zainstalowany pakiet nie chce się uruchomić. Jeśli problem spowodowany jest brakiem zależności lub jej niewłaściwą wersją, możemy naprawić taki problem „wstrzykując” zależność do wirtualnego środowiska zarządzanego przez pipx.

pipx inject yt-dlp <jakaś_biblioteka> lub użyć bezpośrednio pip w tymże środowisku pipx runpip yt-dpl <polecenie pip>.

Do Waszej dyspozycji pozostają też trzy zmienne środowiskowego:

PIPX_HOME — katalog w którym tworzone są wirtualne środowiska (domyślnie: ~/local/pipx/

PIPX_BIN_DIR – katalog w którym zostaną umieszczone symlinki do wykonywalnych poleceń. Oczywiście najlepiej taki, który znajduje się w ścieżce uruchomieniowej. Domyślnie ~/.local/bin.

PIPX_DEFAULT_PYTHON — jeśli chcecie używać innej wersji Pythona

Na zakończenie przypomnę tylko, że pipx nie rozwiązuje magicznie problemu pakietów, które wymagają dostępu do kompilatora i nagłówków — tu nadal musimy zapewnić wszystko przy użyciu pakietów -dev*.

1. Staram się porzucić żywot człowieka używajcego Debian/oldstable żyjącego z 25GiB-towego katalog ~/src ↩
2. zob. „Umówiłem się z nią na dziewiątą” ↩