Niepewna przyszłość menedżera e-booków Calibre: co zrobić, gdy stary język lepszy niż nowy?

Strona główna Aktualności
image

O autorze

Python jest niewątpliwie jednym z najważniejszych języków programowania. Ale Python Pythonowi nierówny – za nieco ponad 13 miesięcy jego wersja 2.7 zostanie oficjalnie porzucona na rzecz Pythona 3, nie do końca z nim kompatybilnego. Ma to poważne konsekwencje dla stworzonego w tym języku oprogramowania. Większość deweloperów bierze się za przepisywanie swoich aplikacji na nowe czasy. Ale niektórzy najwyraźniej wierzą, że sprawdzonych rozwiązań lepiej nie ruszać. Należy do nich Kovid Goyal, twórca calibre, świetnego narzędzia do zarządzania biblioteką e-booków.

Zegar odliczania do końca ery Pythona 2 bezwzględnie odlicza sekundy do 1 stycznia 2020 roku, kiedy to podziękujemy temu zasłużonemu językowi programowania za wierną służbę i tysiące znakomitych projektów software’owych. W teorii nie powinno być z tego powodu dramatu. Większość popularnych pakietów z repozytoriów działa już Pythonie 3, przenoszenie kodu na nową wersję języka jest bardzo dobrze udokumentowane, autorzy najważniejszego napisanego w Pythonie oprogramowania zobowiązali się do porzucenia wsparcia dla Pythona 2 przed nastaniem 2020 roku.

Działa – nie ruszaj?

Jeden się postawił. Calibre (które znajdziecie w naszej bazie oprogramowania na Windowsa i macOS-a) jest programem bez konkurencji w swojej kategorii. Pozwala nie tylko na zarządzanie katalogiem posiadanych e-booków, ale też na wygodną konwersję między przeróżnymi formatami, budowanie własnych książek, edytowanie ich, a za pomocą dodatkowych wtyczek nawet usuwanie zabezpieczeń DRM. Calibre jest też napisane w większości w 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 regularnie poprawiany, ale nigdy chyba nie przepisany od nowa. Poza samym twórcą, Kovidem Goyalem mało kto przy nim cokolwiek robi. I raczej się to nie zmieni, tym bardziej, że Goyal zamierza trzymać się tego co już zrobił z godnym lepszej sprawy uporem.

W zeszłym roku Darwin Wu zgłosił poważny problem z Calibre: Python 2 idzie na emeryturę, a więc czas na przejście na Pythona 3. Odpowiedź autora programu była zaskakująca: nie, nie idzie. Jestem w stanie sam utrzymać Pythona 2. To znacznie mniej roboty niż migrowanie całej bazy kodu Calibre.

Niezły żart? Niekoniecznie. Takie propozycje migracji były zgłaszane już kilkukrotnie wcześniej, za każdym razem odrzucane, i nie bez podstaw. Przepisanie pół miliona linii kodu na nową wersję języka, która jak autor twierdzi gorzej sobie radzi w zastosowaniach, w których błyszczy Python 2, po prostu nie bardzo ma sens. Python 3 po prostu zupełnie inaczej niż Python 2 traktuje ciągi znaków (zmienne łańcuchowe string), co czyni go gorszym w przetwarzaniu pakietów sieciowych czy formatów plików.

Zrób to sam

Co więcej, w tej oczekiwanej konwersji nikt tak naprawdę nie chciał Goyalowi pomóc. Wnajlepszym razie zaoferowano mu moc obliczeniową do uruchomienia narzędzia automatycznej konwersji 2to3, produkującego jak można sobie wyobrazić kod takiej sobie jakości, i wprowadzającego liczne regresje.

Sytuacja jest patowa. Można sobie wyobrazić, że Goyal będzie samodzielnie łatać przez kolejne lata Pythona 2.7 tylko na potrzeby swojego Calibre. Sęk w tym, że eksperci nie raz już zwracali uwagę na bardzo swobodne podejście tego programisty do kwestii bezpieczeństwa – najsłynniejsze było oczywiście wprowadzenie w imię wygody montowania systemów plików z czytników e-booków zmian, programie, które pozwalały każdemu użytkownikowi uzyskać uprawnienia administracyjne. Gdy pojawiły się pierwsze zgłoszenia luk wraz z gotowymi exploitami, Goyal zamiast naprawić problem wypisywał jedynie sarkastyczne komentarze. Czy sarkazm broni przez atakami?

A przecież Calibre jest programem, który z konieczności będzie miał do czynienia z plikami 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że po prostu stać się zagrożeniem dla każdego swojego użytkownika. Porządne załatanie tych dziur jest zaś zdecydowanie ponad siły jednego człowieka. Jeszcze do niedawna można było się spodziewać, że Red Hat pomoże w utrzymaniu Pythona 2.x przez kolejne lata (w końcu za to płacą klienci), ale dziś po kupieniu Red Hata przez IBM-a wcale nie jest to takie pewne. Poza tym mało kto jest w stanie skorzystać z pakietów Pythona dostarczanych dla systemów RHEL czy CentOS.

W tej sytuacji wydaje się nam, że jest tylko jedno wyjście – Tauthon. Tauthon, pierwotnie nazywany Pythonem 2.8, jest jednym z najbardziej bezpośrednich sposobów na utrzymanie Pythona 2 przy życiu. To nic innego niż fork Pythona 2.7.15, w pełni kompatybilny z oficjalną wersją języka, do której stopniowo wprowadzane są najlepsze funkcje Pythona 3, takie jak składnia async/await czy argumenty tylko w postaci słów kluczowych. Czy Goyal mógłby zdecydować się na coś takiego?

© dobreprogramy