Niepewna przyszłość menedżera e‑booków Calibre: co zrobić, gdy stary język lepszy niż nowy?
Python jest niewątpliwie jednym znajważniejszych języków programowania. Ale Python Pythonowinierówny – za nieco ponad 13 miesięcy jego wersja 2.7 zostanieoficjalnie porzucona na rzecz Pythona 3, nie do końca z nimkompatybilnego. Ma to poważne konsekwencje dla stworzonego w tymjęzyku oprogramowania. Większość deweloperów bierze się zaprzepisywanie swoich aplikacji na nowe czasy. Ale niektórzynajwyraźniej wierzą, że sprawdzonych rozwiązań lepiej nieruszać. Należy do nich Kovid Goyal, twórca calibre, świetnegonarzędzia do zarządzania biblioteką e-booków.
Zegar odliczania do końca ery Pythona 2 bezwzględnie odliczasekundy do 1 stycznia 2020 roku, kiedy to podziękujemy temuzasłużonemu językowi programowania za wierną służbę i tysiąceznakomitych projektów software’owych. W teorii nie powinno być ztego powodu dramatu. Większość popularnych pakietów zrepozytoriów działa już Pythonie 3, przenoszenie kodu na nowąwersję języka jest bardzo dobrze udokumentowane,autorzy najważniejszego napisanego w Pythonie oprogramowaniazobowiązali się doporzucenia wsparcia dla Pythona 2 przed nastaniem 2020 roku.
Działa – nie ruszaj?
Jeden się postawił. Calibre (które znajdziecie w naszej bazieoprogramowania na Windowsai macOS-a)jest programem bez konkurencji w swojej kategorii. Pozwala nie tylkona zarządzanie katalogiem posiadanych e-booków, ale też na wygodnąkonwersję między przeróżnymi formatami, budowanie własnychksiążek, edytowanie ich, a za pomocą dodatkowych wtyczek nawetusuwanie zabezpieczeń DRM. Calibre jest też napisane w większościw Pythonie 2.7 z licznymi rozszerzeniami w języku C.
Zarazem jednak Calibre nie jest zbyt pięknie napisanym programem,ma spore problemy z bezpieczeństwem i wydajnością. Jest regularniepoprawiany, ale nigdy chyba nie przepisany od nowa. Poza samymtwórcą, Kovidem Goyalem mało kto przy nim cokolwiekrobi. I raczej się to nie zmieni, tym bardziej, że Goyalzamierza trzymać się tego co już zrobił z godnym lepszej sprawyuporem.
W zeszłym roku Darwin Wu zgłosiłpoważny problem z Calibre: Python 2 idzie na emeryturę, a więcczas na przejście na Pythona 3. Odpowiedź autora programu byłazaskakująca: nie, nie idzie. Jestem w stanie sam utrzymaćPythona 2. To znacznie mniej roboty niż migrowanie całej bazy koduCalibre.
Niezły żart? Niekoniecznie.Takie propozycje migracji były zgłaszane już kilkukrotniewcześniej,za każdym razem odrzucane, i nie bez podstaw. Przepisanie półmiliona linii kodu na nową wersję języka, która jak autortwierdzi gorzej sobie radzi w zastosowaniach, w których błyszczyPython 2, po prostu nie bardzo ma sens. Python 3 po prostu zupełnieinaczej niż Python 2 traktuje ciągi znaków (zmienne łańcuchowestring), co czyni go gorszym w przetwarzaniu pakietów sieciowych czyformatów plików.
Zrób to sam
Co więcej, w tej oczekiwanejkonwersji nikt tak naprawdę nie chciał Goyalowi pomóc. Wnajlepszymrazie zaoferowano mu moc obliczeniową do uruchomienia narzędziaautomatycznej konwersji 2to3,produkującego jak można sobie wyobrazić kod takiej sobie jakości,i wprowadzającego liczne regresje.
Sytuacja jest patowa. Możnasobie wyobrazić, że Goyal będzie samodzielnie łatać przezkolejne lata Pythona 2.7 tylko na potrzeby swojego Calibre. Sęk wtym, że eksperci nie raz już zwracali uwagę na bardzo swobodnepodejście tego programisty do kwestii bezpieczeństwa –najsłynniejsze było oczywiście wprowadzeniew imię wygody montowania systemów plików z czytników e-bookówzmian, programie, które pozwalały każdemu użytkownikowi uzyskaćuprawnienia administracyjne. Gdy pojawiły się pierwsze zgłoszenialuk wraz z gotowymi exploitami, Goyal zamiast naprawić problemwypisywał jedynie sarkastyczne komentarze. Czy sarkazm broni przezatakami?
A przecież Calibre jestprogramem, który z konieczności będzie miał do czynienia zplikami z zewnątrz, w tym być może uzłośliwionymi e-bookami.Działając na Pythonie 2.7 z niezałatanymi porządnie dziurami możepo prostu stać się zagrożeniem dla każdego swojego użytkownika.Porządne załatanie tych dziur jest zaś zdecydowanie ponad siłyjednego człowieka. Jeszcze do niedawna można było się spodziewać,że Red Hat pomoże w utrzymaniu Pythona 2.x przez kolejne lata (wkońcu za to płacą klienci), ale dziś po kupieniu Red Hata przezIBM-a wcale nie jest to takie pewne. Poza tym mało kto jest w stanieskorzystać z pakietów Pythona dostarczanych dla systemów RHEL czyCentOS.
W tej sytuacji wydaje się nam,że jest tylko jedno wyjście – Tauthon.Tauthon, pierwotnie nazywany Pythonem 2.8, jest jednym z najbardziejbezpośrednich sposobów na utrzymanie Pythona 2 przy życiu. To nicinnego niż fork Pythona 2.7.15, w pełni kompatybilny z oficjalnąwersją języka, do której stopniowo wprowadzane są najlepszefunkcje Pythona 3, takie jak składnia async/await czy argumentytylko w postaci słów kluczowych. Czy Goyal mógłby zdecydować sięna coś takiego?
