Wirtualne środowiska i zarządzanie zależnościami w Pythonie: Od venv do Poetry

Każdy, kto spędził w Pythonie więcej niż kilka dni, prawdopodobnie zderzył się z problemem wersji bibliotek. Klasyczny scenariusz: jeden projekt wymaga starszej wersji frameworka Django, a nowy potrzebuje najnowszych funkcji. Instalowanie wszystkiego globalnie w systemie operacyjnym to najprostsza droga do tzw. dependency hell (piekła zależności).

W tym artykule przyjrzymy się, jak profesjonalnie podejść do tematu izolacji środowisk. Przejdziemy drogę od tradycyjnego, wbudowanego narzędzia `venv` po nowoczesny standard, jakim staje się `Poetry`, analizując ich wady, zalety i zastosowanie w codziennej pracy dewelopera oraz systemach CI/CD.

Dlaczego globalna instalacja to błąd?

Większość systemów operacyjnych (szczególnie Linux i macOS) opiera się na Pythonie do obsługi wewnętrznych skryptów systemowych. Nadpisanie systemowej wersji biblioteki za pomocą polecenia `sudo pip install` może uszkodzić krytyczne narzędzia systemowe. Co więcej, brak izolacji uniemożliwia pracę nad wieloma projektami jednocześnie, jeśli wymagają one różnych wersji tych samych bibliotek.

Rozwiązaniem tego problemu są wirtualne środowiska. Tworzą one odizolowaną przestrzeń (katalog) dla każdego projektu, posiadającą własny interpreter Pythona i niezależne drzewo zainstalowanych pakietów. Dzięki temu zmiany w jednym projekcie nie wpływają na pozostałe.

Klasyczny duet: venv i pip

Standardowa biblioteka Pythona oferuje moduł `venv`, który od wersji 3.3 jest domyślnym narzędziem do tworzenia wirtualnych środowisk. W połączeniu z menedżerem pakietów `pip` stanowi on fundament większości starszych i prostszych projektów.

# Tworzenie wirtualnego środowiska o nazwie .venv
python3 -m venv .venv

# Aktywacja środowiska (Linux/macOS)
source .venv/bin/activate

# Aktywacja środowiska (Windows - PowerShell)
.venv\Scripts\Activate.ps1

Po aktywacji środowiska, każde wywołanie `pip install` instaluje pakiety wewnątrz katalogu `.venv`. Standardem zapisu zależności w tym podejściu jest plik `requirements.txt`. Generuje się go za pomocą polecenia `pip freeze > requirements.txt`, a odtwarza na innej maszynie przez `pip install -r requirements.txt`.

Gdzie klasyczny duet venv + pip zaczyna zawodzić?

Choć `venv` i `pip` są świetne na start, w profesjonalnych projektach zespołowych szybko ujawniają swoje ograniczenia:

• Brak determinizmu: Plik `requirements.txt` często zawiera luźno określone wersje (np. `requests>=2.25.0`), co sprawia, że instalacja na innej maszynie może pobrać nowszą, potencjalnie psującą kod wersję sub-zależności.
• Brak rozróżnienia środowisk: Nie ma prostego sposobu na oddzielenie bibliotek potrzebnych tylko do testów i developmentu (np. `pytest`, `black`) od tych wymaganych na produkcji. Tworzy się wtedy sztuczne pliki typu `requirements-dev.txt`.
• Słabe rozwiązywanie konfliktów: `pip` przez lata instalował pakiety "na oślep", potrafiąc nadpisać zależność innej biblioteki bez ostrzeżenia.

Nowa era: Poetry jako nowoczesny standard

W odpowiedzi na te bolączki powstało narzędzie Poetry. Łączy ono w sobie funkcje zarządzania środowiskami wirtualnymi, menedżera pakietów, mechanizmu budowania aplikacji oraz publikowania jej w repozytoriach (np. PyPI). Poetry opiera się na standardzie PEP 518 i pliku `pyproject.toml`, który zastępuje nie tylko `requirements.txt`, ale również pliki konfiguracyjne innych narzędzi.

Jak działa Poetry pod maską?

Kluczem do sukcesu Poetry jest rozdzielenie zależności na dwa pliki:

1. `pyproject.toml` – zawiera deklaracje bezpośrednich zależności zdefiniowane przez programistę (np. "potrzebuję FastAPI w wersji ^0.95.0").
2. `poetry.lock` – automatycznie generowany plik zawierający dokładne, zablokowane wersje wszystkich zainstalowanych pakietów wraz z ich sumami kontrolnymi (hashami). Dzięki temu każdy programista w zespole i serwer CI/CD zainstaluje dokładnie ten sam zestaw bitów.

# Inicjalizacja nowego projektu z Poetry
poetry new moj-projekt
cd moj-projekt

# Dodanie zależności produkcyjnej
poetry add fastapi

# Dodanie zależności deweloperskiej (tylko do testów)
poetry add pytest --group dev

# Instalacja środowiska na podstawie pliku lock (np. na CI/CD)
poetry install --no-root

Porównanie: venv + pip vs Poetry

Poniższa tabela podsumowuje kluczowe różnice między tradycyjnym podejściem a nowoczesnym standardem, jakim jest Poetry.

Dobre praktyki w pracy zespołowej

Wdrożenie odpowiednich narzędzi to połowa sukcesu. Równie ważna jest kultura pracy z zależnościami w zespole oraz na środowiskach CI/CD:

1. Zawsze commituj plik lock: Plik `poetry.lock` MUSI trafić do repozytorium Git. Bez tego praca zespołowa traci gwarancję spójności środowisk.
2. Wykorzystaj cache w CI/CD: Instalowanie pakietów od zera przy każdym pipeline drastycznie wydłuża buildy. Cachuj katalogi z pakietami (np. `~/.cache/pypoetry`) na podstawie hasha pliku lock.
3. Regularne aktualizacje: Korzystaj z narzędzi takich jak Dependabot, które automatycznie otwierają Pull Requesty z aktualizacjami zależności i testują, czy nie psują one aplikacji.

Podsumowanie

Wybór między `venv` a `Poetry` zależy od skali projektu. Dla małych, jednorazowych skryptów `venv` jest w zupełności wystarczający i nie wymaga instalacji dodatkowych narzędzi. Jednak w przypadku projektów komercyjnych, pracy w zespole oraz budowania pipeline'ów CI/CD, Poetry to absolutny standard, który oszczędza czas i zapobiega błędom na produkcji.