Gdy małe biuro przejmuje aplikację w Pythonie lub konfiguruje komputer na nowo, powinno mieć możliwość prześledzenia zestawu jej pakietów. Za pomocą venv i pip można przygotować kontrolowane odtworzenie środowiska. Kluczowe są czyste środowisko wyjściowe, zweryfikowane zależności i testy aplikacji. Sam eksport pakietów nie gwarantuje odtwarzalności w każdych warunkach.
1. Określ wymagania wstępne i katalog roboczy
Wszystkie poniższe przykłady dla systemów uniksowych należy wykonywać wyłącznie w osobnym projekcie testowym, a nie w katalogu aplikacji produkcyjnej. Warunkiem jest już zainstalowany, utrzymywany i zgodny z projektem interpreter Pythona. Wcześniej udokumentuj:
- planowaną wersję interpretera, w tym wersję podrzędną,
- system operacyjny i architekturę procesora,
- stan projektu, wymaganą konfigurację i dostępne testy aplikacji.
python3 oznacza tutaj ten świadomie wybrany interpreter. Przed rozpoczęciem sprawdź, na który interpreter wskazuje to polecenie; w razie potrzeby użyj jawnej ścieżki do niego. Nie zastępuj systemowego Pythona ani nie zmieniaj globalnej zmiennej PATH. Wszystkie ścieżki względne odnoszą się do katalogu głównego projektu testowego. Nazwy plików takie jak requirements-snapshot.txt są dowolnie wybranymi nazwami przykładowymi i w razie zmiany należy je konsekwentnie dostosować we wszystkich miejscach.
2. Przygotuj czyste środowisko źródłowe
Dla planowanego stanu projektu utwórz osobne, początkowo czyste środowisko:
python3 -m venv .venv-srcZainstaluj w nim wyłącznie zależności przewidziane dla projektu testowego, zgodnie z jego instrukcją instalacji. Używaj przy tym jawnie .venv-src/bin/python -m pip, aby przypadkowo nie wykonać operacji w innym środowisku. Nie przejmuj niezweryfikowanego zbioru pakietów ze współdzielonego środowiska roboczego i nie przeprowadzaj zbiorczych aktualizacji pakietów.
Zgodnie z dokumentacją venv pakiety projektu są domyślnie odizolowane. Środowisko pozostaje jednak powiązane ze swoim interpreterem bazowym i nie jest piaskownicą bezpieczeństwa. Aktywacja nie jest konieczna, jeśli używasz jawnych ścieżek do interpretera. Przetestuj teraz aplikację przy użyciu odpowiednich danych testowych; dopiero potem wykonaj eksport.
3. Zapisz i sprawdź przetestowany zestaw pakietów
.venv-src/bin/python -m pip freeze > requirements-snapshot.txtpip freeze podaje zainstalowane pakiety. Nie jest narzędziem rozwiązującym zależności w celu utworzenia pliku blokady i domyślnie pomija niektóre pakiety służące do inicjalizacji środowiska. Plik jest więc wyjściowym zapisem stanu, a nie pełnym opisem interpretera, narzędzi i platformy.
Otwórz wyeksportowany plik przed każdym udostępnieniem. Sprawdź w szczególności instalacje w trybie edytowalnym, ścieżki lokalne i adresy URL prywatnych pakietów. Usuń dane dostępowe z udostępnianych plików. Jednocześnie ustal, w jaki sposób wymagane prywatne pakiety pozostaną dostępne dla uprawnionych użytkowników; samo usunięcie takich wpisów nie zapewni kompletnego odtworzenia środowiska. Zapisz zależności bezpośrednie i przechodnie, zamiast wymieniać tylko biblioteki używane bezpośrednio.
4. Odtwórz środowisko niezależnie i zweryfikuj je
Pozostaw .venv-src bez zmian. Obok niego utwórz drugie środowisko za pomocą odpowiedniego, zgodnego interpretera i zainstaluj zweryfikowaną listę:
python3 -m venv .venv-rebuild
.venv-rebuild/bin/python -m pip install -r requirements-snapshot.txt
.venv-rebuild/bin/python -m pip checkpip check sprawdza wyłącznie deklarowaną zgodność zależności. Wynik bez zastrzeżeń nie zastępuje ani testów aplikacji, ani audytu bezpieczeństwa. Dlatego przeprowadź te same kontrole funkcjonalne co w środowisku źródłowym: na przykład przewidziany import, typowy przebieg przetwarzania i kontrolę wyników. Również te kontrole uruchamiaj jawnie za pomocą .venv-rebuild/bin/python. Udokumentuj błędy i wyniki testów, zanim zaakceptujesz odtworzone środowisko.
5. Dokładniej udokumentuj platformę i pliki pakietów
Aby ułatwić prześledzenie procesu, zapisz dodatkowo używane wersje Pythona i pip oraz system operacyjny i architekturę. Zgodnie z instrukcją pip dotyczącą powtarzalnych instalacji pełne ustalenie wersji zależności bezpośrednich i przechodnich oraz zweryfikowane skróty kryptograficzne pakietów mogą dodatkowo zabezpieczyć ten proces. Skróty potwierdzają zgodność z oczekiwanymi plikami pakietów, a nie brak złośliwego oprogramowania. Archiwa wheel mogą być specyficzne dla danej platformy; zestaw wersji pakietów dostępny dla innej architektury nie jest więc automatycznie równoważny.
6. Zabezpiecz możliwość powrotu i udokumentuj wynik
Zachowaj dotychczasowe środowisko oraz kopię zapasową aplikacji i danych do czasu zweryfikowania nowego środowiska. W razie błędów usuń tylko nowe środowisko testowe i zbadaj przyczynę; dotychczasowa podstawa pracy pozostaje nienaruszona. Środowiska wirtualne tworzy się od nowa, a nie przenosi ani kopiuje.
Podsumowanie: Użyteczne odtworzenie środowiska obejmuje zweryfikowany eksport pakietów, udokumentowaną platformę i pomyślnie zakończone testy aplikacji. Takie połączenie pozwala prześledzić zmiany bez mylenia listy pakietów z kompleksową gwarancją odtwarzalności.