Python venv Cheatsheet

niektóre przydatne polecenia venv

Page content

Venv to narzędzie do zarządzania wirtualnymi środowiskami w wierszu poleceń. Bardziej prosty niż Anaconda. Oto niektóre przydatne polecenia venv.

Python próbuje otworzyć drewnianą skrzynię.

Dla Twojej wiedzy, istnieje znacznie lepsze, według mojej opinii, narzędzie do zarządzania pakietami i środowiskami w Pythonie niż venv – uv. Sprawdź: uv - Nowy menedżer pakietów, projektów i środowisk Pythona

Skrótka dla Python venv

Utworzenie wirtualnego środowiska

  • Standardowe polecenie (Python 3.3+):

    python -m venv venv

    Tworzy wirtualne środowisko o nazwie venv w bieżącym katalogu.

  • Z określonym wersją Pythona (jeśli zainstalowana):

    python3.10 -m venv venv

    lub używając virtualenv:

    virtualenv -p /usr/local/bin/python3.10 venv

    (Wymaga pakietu virtualenv).

Aktywacja wirtualnego środowiska

  • Na Windows: 
    .\venv\Scripts\activate
  • Na macOS/Linux: 
    source venv/bin/activate
    Teraz powłoka powinna wyświetlać nazwę środowiska.

Deaktywacja wirtualnego środowiska

  • Wszystkie platformy: 
    deactivate
    Zwraca Cię do domyślnego Pythona systemowego.

Instalacja pakietów

  • Za pomocą pip: 
    pip install
    Przykład: 
    pip install numpy pandas
  • Aktualizacja pip (zalecana): 
    python -m pip install --upgrade pip

Zamrażanie i eksportowanie wymagań

  • Zapisanie aktualnych pakietów w środowisku: 
    pip freeze > requirements.txt
  • Instalacja z pliku wymagań: 
    pip install -r requirements.txt
    Upewnij się, że wirtualne środowisko jest aktywowane przed uruchomieniem tych poleceń.

Usuwanie wirtualnego środowiska

deactivate
rm -rf <env path>

Powszechne pułapki przy zarządzaniu wirtualnymi środowiskami Pythona

Zapominanie o aktywacji wirtualnego środowiska

  • Częsty błąd to uruchamianie poleceń bez aktywowania zamierzonego wirtualnego środowiska, co prowadzi do instalacji pakietów w środowisku globalnym lub niewłaściwym venv. Może to spowodować konflikty zależności i nieprzewidywalne zachowanie.

Nie blokowanie wersji pakietów

  • Użycie luźnych specyfikatorów wersji (np. >= zamiast ==) w pliku requirements.txt osłabia powtarzalność. Dokładne blokowanie wersji zapewnia, że wszyscy pracujący nad projektem używają tych samych wersji pakietów, zapobiegając nieoczekiwany problemom podczas wdrażania lub współpracy.

Mieszanie środowisk globalnych i wirtualnych

  • Przypadkowa instalacja pakietów globalnie lub mieszanie środowisk globalnych i wirtualnych może tworzyć konflikty, zwłaszcza jeśli różne projekty wymagają niezgodnych wersji pakietów. Zawsze upewnij się, że pracujesz w odpowiednim środowisku.

Dodawanie środowisk wirtualnych do kontroli wersji

  • Włączanie katalogu środowiska wirtualnego (np. venv/) do kontroli wersji zwiększa rozmiar repozytorium i jest zbędne. Zawsze dodawaj katalogi venv do .gitignore, aby utrzymać repozytorium czyste.

Ignorowanie rozdzielania zależności deweloperskich i produkcyjnych

  • Nie rozróżnianie zależności deweloperskich i produkcyjnych może prowadzić do nadmiernej lub niebezpiecznej wdrażania. Używaj osobnych plików wymagań lub sekcji konfiguracji dla każdego.

Brak dokumentacji i automatyzacji

  • Nie dokumentowanie kroków konfiguracji środowiska lub nieautomatyzowanie procesu (za pomocą skryptów lub Makefile) utrudnia onboarding nowych współpracowników i powtarzalność środowisk.

Nie czyszczenie starych środowisk

  • Z czasem, nieużywane wirtualne środowiska mogą się kumulować, zużywając miejsce na dysku i powodując zamęt. Regularnie usuwaj przestarzałe venv, aby utrzymać porządek w przestrzeni roboczej.

Ignorowanie granic systemowego Pythona i menedżera pakietów

  • Modyfikowanie systemowego Pythona lub mieszanie menedżerów pakietów systemowych z pip może zniszczyć narzędzia systemowe i wprowadzać trudne do diagnozowania problemy. Zawsze używaj venv do zależności projektu i unikaj interwencji w pakiety zarządzane przez system.

Tabela podsumowująca

Pułapka Wpływ
Zapominanie o aktywacji venv Instaluje pakiety w niewłaściwym środowisku
Nie blokowanie wersji pakietów Nieprzewidywalne budowanie, trudne do odtworzenia błędy
Mieszanie środowisk globalnych i wirtualnych Konflikty zależności/wersji
Dodawanie katalogów venv do kontroli wersji Zwiększa rozmiar repozytorium, chaotyczne repozytorium
Nie rozdzielanie zależności deweloperskich i produkcyjnych Nadmierny/niebezpieczny wdrożenie środowisk
Brak dokumentacji/automatyzacji Trudny onboarding, niezgodne konfiguracje
Nie czyszczenie starych środowisk Marnotrawstwo miejsca na dysku, zamęt
Modyfikowanie systemowego Pythona lub pakietów Niestabilność systemu, zniszczone narzędzia

Dzięki przestrzeganiu najlepszych praktyk, takich jak zawsze aktywowanie venv, blokowanie zależności, rozdzielanie środowisk i utrzymywanie jasnej dokumentacji, możesz uniknąć tych powszechnych pułapek.

Kluczowe różnice między środowiskami Conda a wirtualnymi środowiskami Pythona dla powtarzalności

Funkcja Środowiska Conda Wirtualne środowiska Pythona (venv/virtualenv)
Zakres zarządzania Zarządza pakietami Pythona i zależnościami nie- Pythona (np. biblioteki systemowe, kompilatory) Zarządza tylko pakietami Pythona za pomocą pip
Kontrola wersji Pythona Można określić i zainstalować dowolną wersję Pythona na środowisko Używa wersji Pythona zainstalowanej w systemie
Zgodność międzyplatformowa Większa zgodność między różnymi systemami (Windows, macOS, Linux) dzięki zarządzaniu wszystkimi zależnościami Opiera się na bibliotekach systemowych, które mogą się różnić w zależności od systemu
Źródła pakietów Używa repozytoriów Conda (przełożone binarki, stos naukowy) Używa PyPI (pip) dla pakietów Pythona
Powtarzalność Wysoka dla złożonych, naukowych lub wielojęzycznych projektów; można eksportować pełne środowisko (conda env export) Dobra dla czystych projektów Pythona; może brakować powtarzalności, jeśli są zaangażowane zależności systemowe
Zależności nie- Pythona Można zainstalować i zarządzać (np. OpenBLAS, libpng) Nie można zarządzać; muszą być zainstalowane osobno
Eksportowanie/importowanie środowiska conda env export / conda env create dla pełnej powtarzalności pip freeze > requirements.txt / pip install -r requirements.txt (tylko pakiety Pythona)
Wydajność Szybsze i bardziej niezawodne dla dużych pakietów naukowych (np. numpy, pandas) Może wymagać kompilowania z źródeł, zwłaszcza na Windows
Złożoność Słabo wyższy poziom konfiguracji i zarządzania Lekki, prostszy dla podstawowych projektów Pythona

Podsumowanie kluczowych punktów

  • Środowiska Conda są idealne dla powtarzalności w projektach wymagających zarówno pakietów Pythona, jak i zależności nie- Pythona, lub gdy dokładna replikacja między platformami jest krytyczna. Conda zarządza całą strukturą – w tym samym Pythonie, bibliotekami i nawet kompilatorami – co ułatwia udostępnianie i powtarzalność złożonych środowisk, szczególnie w kontekście nauki danych i badań.

  • Wirtualne środowiska Pythona (venv/virtualenv) są lekkie i świetne do izolowania zależności Pythona w projektach czysto Pythona. Jednak nie zarządzają zależnościami systemowymi ani nie- Pythona, więc powtarzalność może być zagrożona, jeśli projekt zależy od bibliotek zewnętrznych lub konkretnych konfiguracjach systemowych.

  • Eksportowanie i udostępnianie środowisk: Conda pozwala na eksport pełnej specyfikacji środowiska (conda env export), w tym wszystkich zależności i ich wersji, które można dokładnie odtworzyć w innym miejscu. Z wirtualnymi środowiskami pip freeze zapisuje tylko pakiety Pythona, nie zależności systemowe ani wersję interpretera Pythona.

  • Podsumowanie
    Używaj Conda dla maksymalnej powtarzalności w projektach naukowych, międzyplatformowych lub złożonych projektach. Używaj wirtualnych środowisk Pythona dla lekkich, czystych projektów Pythona, gdzie zależności systemowe nie są kwestią znaczenia.

Przydatne linki