Zrozum przełomowe zmiany w pakietach Qiskit v1.0

Qiskit v1.0 używa innej struktury pakietów niż poprzednie wersje Qiskit i prawdopodobnie spowoduje problemy w środowiskach korzystających z pakietów, które nie są jeszcze gotowe na Qiskit v1.0.

ostrożnie

Nie próbuj aktualizować istniejącego wirtualnego środowiska Pythona do Qiskit v1.0 w miejscu.

W przyszłości nie będziemy wprowadzać podobnych przełomowych zmian w pakowaniu. To jednorazowe zdarzenie, przy wydaniu Qiskit v1.0, specjalnie po to, aby nasze podejście do pakietów było jak najprostsze w przyszłości.

Ta strona zawiera szczegółowe informacje na temat pakietu Qiskit sprzed wersji 1.0 oraz powodów, dla których wprowadziliśmy przełomowe zmiany w pakowaniu.

Wiemy, że ta zmiana jest uciążliwa, ale przywraca ona Qiskit do prostej struktury pakietów, z której korzysta większość pakietów Pythona. Po zakończeniu przejścia na Qiskit v1.0 będzie to łatwiejsze dla użytkowników, deweloperów i autorów bibliotek.

Wstęp: słownik terminologii pakietowania Pythona

Aby lepiej wyjaśnić, jak był zbudowany stary metapackage Qiskit i co zmieniło się wraz z wydaniem Qiskit v1.0, poniżej znajduje się słownik często używanego żargonu związanego z pakowaniem w Pythonie. Poniższe słowa mają konkretne znaczenia, których będziemy używać w tym dokumencie.

Kliknij tutaj, aby przejrzeć słownik tej strony

• moduł: Pojedynczy plik Pythona.

• pakiet: Katalog zawierający __init__.py oraz inne pliki lub pakiety, które Python może odczytać. To jest właściwy kod zainstalowany na twoim komputerze i to on wykonuje się, gdy uruchamiasz import something. Python traktuje każdy katalog znajdujący się na ścieżce wyszukiwania jako coś, co możesz importować (i zaimportuje wiele dodatkowych elementów).

  Nie jest to ten sam obiekt, który instalujesz przez pip install (co jest dystrybucją), ale zazwyczaj to, co instalujesz przez pip install, i to, co importujesz przez import, ma tę samą nazwę.

• submoduł, subpakiet: Są to nieprecyzyjne terminy, ale są powszechnie używane. Człon sub oznacza „zawarty wewnątrz pakietu". Submoduł jest modułem, a subpakiet jest pakietem, ale są one częścią większego pakietu.

• pakiet przestrzeni nazw: Pakiet, do którego inne dystrybucje mogą instalować submoduły lub subpakiety. Co ważne, żadna dystrybucja uczestnicząca w pakiecie przestrzeni nazw niekoniecznie jest właścicielem wszystkich zainstalowanych plików, więc jego całkowite odinstalowanie lub aktualizacja może być trudna.

• dystrybucja: Skompresowane pliki Pythona, pliki danych i metadane pobierane podczas uruchamiania pip install something. Zazwyczaj dystrybucja zawiera dokładnie jeden pakiet oraz metadane dotyczące sposobu jego instalacji (wymagania itp.), ale nie jest to wymagane. Dystrybucja może zawierać zero lub więcej modułów albo pakietów.

  Jeśli znasz „menedżery pakietów" spoza kontekstu Pythona, takie jak apt z Debian/Ubuntu lub Homebrew na macOS, to to, co one nazywają „pakietem", Python nazywa dystrybucją, i nie ma dokładnego odpowiednika tego, co Python nazywa pakietem.

  Większość źródeł mówiących o pakowaniu w Pythonie używa terminu pakiet w odniesieniu zarówno do dystrybucji, jak i pakietów, i trzeba odwoływać się do kontekstu, aby zrozumieć, co jest miane na myśli. Ogólnie rzecz biorąc, jeśli coś importujesz, źródło ma na myśli „pakiet", a jeśli coś instalujesz przez pip install, źródło ma na myśli „dystrybucję".

• ścieżka wyszukiwania: Próbując wykonać import something, Python przeszukuje z góry określoną listę miejsc w poszukiwaniu modułu lub pakietu o nazwie something. Ta lista miejsc to ścieżka wyszukiwania. Możesz ją przeglądać i modyfikować w sys.path.

• wymaganie: Dystrybucja zawiera informacje o innych dystrybucjach, od których zależy po zainstalowaniu. Każda inna niezbędna dystrybucja jest wymaganiem, a menedżer pakietów (zazwyczaj pip lub conda) powinien zapewnić, że wszystkie wymagania są zainstalowane w zgodnych wersjach.

Python jest bardzo dynamiczny i może powstawać wiele komplikacji; na przykład możliwe jest, że moduł lub pakiet nie odpowiada plikom na dysku lub że są to skompilowane rozszerzenia.

Ścieżka wyszukiwania to nie tylko przeszukiwanie katalogów, ale na potrzeby tej dyskusji istotne są wyłącznie pliki na dysku. Dalsze komplikacje nie są konieczne do zrozumienia problemów opisanych w tej sekcji, więc możesz korzystać z opisanego powyżej modelu.

Stara struktura Qiskit

Historycznie Qiskit składał się z wielu dystrybucji Pythona: qiskit-terra, rdzeń kompilatora; qiskit-aer, wydajny symulator; oryginalny dostawca IBM Quantum®; oraz kilka przestarzałych pakietów oferujących konkretne eksploracyjne funkcje algorytmiczne lub uruchamiania eksperymentów. Dla wygody użytkowników udostępnialiśmy również dystrybucję Pythona o nazwie qiskit, która nie zawierała własnego kodu, ale powodowała instalację wszystkich pozostałych komponentów. Nazywaliśmy to metapackage'em, przez analogię do podobnych koncepcji w innych menedżerach pakietów. Kod rdzenia Qiskit znajdował się w qiskit-terra, który był właścicielem katalogu głównego pakietu Pythona qiskit. Innymi słowy, qiskit-terra kontrolował to, co działo się po uruchomieniu import qiskit. Do Qiskit v1.0 pakiet qiskit był pakietem przestrzeni nazw i zawierał drugi pakiet przestrzeni nazw pod ścieżką qiskit.providers.

Ta organizacja stwarzała nam i naszym użytkownikom sporo problemów.

Na przykład biblioteki zewnętrzne zależące od Qiskit często potrzebowały tylko rdzenia kompilatora i nie wymagały całego dużego ekosystemu dostarczanego przez pip install qiskit. Dlatego słusznie określały swoje wymaganie jako qiskit-terra. Jednak gdy ludzie próbowali odinstalować Qiskit przez uruchomienie pip uninstall qiskit, pip napotykał problemy:

• pip nie usuwa dystrybucji, które nie są już używane. Tak więc pip uninstall qiskit niemal nic nie robiło; w dystrybucji nie było kodu, więc żaden kod nie był usuwany.
• Nawet gdyby usunął kod, wiele dystrybucji zewnętrznych nadal pozostawałoby zainstalowanych, ponieważ zależały od qiskit-terra.
• Nawet jeśli qiskit-terra zostałby odinstalowany, mógłby nadal pozostawić możliwy do zaimportowania katalog qiskit bez użytecznego kodu, ponieważ był to pakiet przestrzeni nazw.

Podczas instalowania lub aktualizowania dystrybucji za pomocą polecenia pip install, pip również nie bierze pod uwagę poprzednich rozwiązań wymagań. Ponieważ istniały dwa pakiety, aktualizacja pakietu wymagającego aktualizacji qiskit-terra powodowała nieprawidłowe środowisko; pip aktualizował qiskit-terra, ale pozostawiał qiskit bez zmian. Generował ostrzeżenie przy tym i wszystkich kolejnych poleceniach pip install, ale ponieważ nic nie wyglądało na zepsute, użytkownicy zazwyczaj ignorowali ostrzeżenie, a pip nie zgłaszał błędu ani nie blokował operacji.

Z czasem usuwaliśmy elementy z metapackage'u qiskit, aż od Qiskit v0.44 pozostał tylko qiskit-terra. Spośród tych komponentów qiskit-aer nadal istnieje i jest aktywnie aktualizowany, ale teraz jest instalowany jako oddzielna dystrybucja.

Podobnie coraz mocniej zniechęcaliśmy inne biblioteki do korzystania z hooków przestrzeni nazw. Usunęliśmy ostatnie użycie hooków przez Qiskit w nieobsolętnych pakietach wraz z wydaniem Qiskit Aer v0.11 i jego nowym pakietem Pythona qiskit_aer, choć do Qiskit v1.0 wymuszaliśmy też działanie ścieżki przestrzeni nazw qiskit.providers.aer. Począwszy od Qiskit v1.0 usunęliśmy możliwość rozszerzania przez pakiety jakiejkolwiek przestrzeni nazw qiskit. Dzięki temu pip uninstall na właściwej dystrybucji w prawidłowym środowisku działa teraz zgodnie z oczekiwaniami.

Nowa struktura Qiskit

Począwszy od wersji 1.0, Qiskit składa się z jednej dystrybucji o nazwie qiskit, która instaluje jeden pakiet, również o nazwie qiskit, będący właścicielem całego kodu zawartego w swoim katalogu. To jest normalna struktura kodu Pythona i jest najprostsza oraz najmniej podatna na błędy.

Dystrybucja qiskit-terra w PyPI nigdy nie zostanie zaktualizowana do wersji 1.0 ani wyższej; jest całkowicie zastąpiona przez qiskit. Nazwa qiskit-terra nie jest już zaangażowana w proces instalacji. Jednak pakiet qiskit-terra nie jest usuwany z PyPI i pozostawimy jego najnowszą wersję w działającym stanie, aby stary kod naukowy i starsze pakiety mogły z niego łatwiej korzystać.

Niestety, ze względu na dziedzictwo metapackage'u i niedoskonałości pip jako menedżera pakietów, nie jest możliwe zapewnienie całkowicie płynnej ścieżki aktualizacji do Qiskit v1.0, szczególnie gdy niektóre pakiety zależą od wcześniejszych wersji Qiskit, a inne wymagają wyłącznie Qiskit v1.0+. Problemy te będą się zmniejszać w miarę jak coraz więcej ekosystemu migruje do Qiskit v1.0.

Gdzie podziały się moduły aplikacyjne?

Możesz zauważyć, że polecenie pip install qiskit nie będzie już zawierać pakietów takich jak qiskit-aer czy qiskit-nature. Wraz z usunięciem struktury metapackage'u, wiele z tych pakietów zostało podzielonych na dystrybucje, które należy instalować osobno.

Przed wydaniem Qiskit SDK v1.0, Qiskit składał się z wielu różnych dystrybucji Pythona, takich jak qiskit-terra, rdzeń kompilatora; qiskit-aer, wydajny symulator; oryginalny dostawca IBM Quantum®; oraz kilka przestarzałych pakietów oferujących konkretne eksploracyjne funkcje algorytmiczne lub uruchamiania eksperymentów.

Jeśli chcesz zainstalować pakiety, które były wcześniej zawarte w metapackage'u Qiskit, odwiedź ekosystem Qiskit, aby znaleźć szereg pakietów odpowiadających twoim potrzebom. Możesz też przeczytać przewodnik migracji do v1.0, aby uzyskać więcej informacji na temat instalacji nowej dystrybucji.