Czym jest Python Virtual Environment (venv)?

Python Virtual Environment (potocznie venv – tego skrótu będziemy używać najczęściej) jest środowiskiem Pythona, które jest odseparowane i całkowicie niezależne od głównej instalacji Pythona. Każdy tworzony przez nas projekt może, a nawet powinien, zawierać swoje środowisko, dzięki czemu może składać się z unikalnego zestawu pakietów.

Brzmi zawile? Bardzo upraszczając – venv jest nowym katalogiem na dysku, w którym znajduje się kopia Pythona. Zaraz po utworzeniu zawiera ona jedynie podstawowe pakiety. Zupełnie tak, jakbyśmy zainstalowali Pythona sami w nowej lokalizacji.

Różnica polega na tym, że venv tworzymy za pomocą jednego polecenia i oczywiście potrzebny jest już wcześniej zainstalowany Python. Nie zaśmiecamy sobie w żaden sposób systemu i możemy tworzyć dowolnie dużą liczbę takich środowisk.

W prosty sposób można aktywować venv (jak? – zrobimy to już w następnych lekcjach), doinstalować tylko te pakiety, których potrzebujemy, oraz uruchamiać stworzone przez nas skrypty.

Po co stosować venv? Jakie ma zalety?

Największą i niewątpliwą zaletą venv jest izolacja środowiska Python dla danego projektu. Dzięki temu, każde stworzone przez nas środowisko, może mieć własny zestaw pakietów, który jest wymagany dla danego projektu.

Często dochodzi do sytuacji, gdy projekty nad którymi pracujemy wymagają różnych wersji pakietów, albo pakietów, które nie są kompatybilne ze sobą. Venv pozwala na pełną dowolność w komponowaniu zestawu potrzebnych bibliotek, dzięki czemu możemy mieć jednocześnie środowisko o nazwie venv1 z pakietami w wersji 1.0 oraz venv2 z pakietami w wersji 2.0 z możliwością szybkiego i bezproblemowego przełączania się między nimi.

Zobacz sam jak może przykładowo wyglądać stan instalacji Pythona, pakietów i projektów bez zastosowania venv:

I po zastosowaniu venv, czy dostrzegasz teraz zalety tego podejścia?:

Możemy bez przeszkód korzystać z czystego Pythona i usuwać dane projekty wraz z ich pakietami oraz dodawać nowe bazując oczywiście na czyściutkim Pythonie 😀

Stosując wirtualne środowiska dbamy także o “czystość” danej instancji venv – łatwo możemy “zamrozić” (innymi słowy spisać) wersje pakietów a następnie, w równie prosty sposób, odtworzyć nasze środowisko w dowolnym miejscu na dowolnej maszynie. Ułatwia to także dzielenie się kodem i umieszczanie go w repozytorium, bo zamiast całego folderu ze wszystkimi zainstalowanymi pakietami (i czesto tysiącami plików) wystarczy umieści tylko jeden z wymaganymi nazwami i wersjami pakietów.

Dodatkowo samo tworzenie wirtualnego środowiska jest bardzo proste i nie ingeruje w żaden sposób w system. Pozwala to na większą swobodę i możliwość eksperymentowania – w przypadku niepowodzenia można w prosty sposób usunąć dany venv i stworzyć całkowicie nowy i czysty.

Minusem stosowania venv jest fakt, iż każde kolejne stworzone wirtualne środowisko zajmuje miejsce na dysku. Czysty venv zajmuje ok 30 MB a każdy kolejny pakiet zwiększa tą wartość. Jeśli mamy kilkanaście projektów, a każdy z nich będzie posiadał własne środowisko, to szybko wskoczymy na wartości setek MB. Nie są to duże wartości w obecnych czasach, ale warto mieć je na uwadze.

Co zyskujemy w naszych testach?

W końcu pozbędziemy się problemów z konfliktami w systemie, gdy w PyCharm działaliśmy na innym środowisku a w konsoli Windows rozpoznawane było inne – teraz my rządzimy!

Łatwiej będzie nam identyfikować błędy, gdy do naszych testów użyjemy wyłącznie potrzebnych pakietów.

Ucz się Pythona w dowolny sposób i z dowolnymi pakietami, ale testy mają działać na jak najczystszym środowisku 🙂

Wracając do nauki – instalujesz i eksperymentujesz a następnie usuwasz bez obawy, że naśmieciłeś w swoim systemie oraz, że coś popsujesz przy próbie odśmiecania 😀

PyCharm od wersji 2018 domyślnie sugeruje środowiska wirtualne i dlatego skorzystamy z nich i my 🙂

Drogi testerze – unikniesz problemów z twoimi testami, które nie działają na innych maszynach, gdy ktoś poza tobą będzie chciał je uruchomić 🙂

Same zalety (?) – są oczywiście i wady… trzeba je poznać aby bezpiecznie stosować venv 😉

3 komentarze

  1. Pingback: Testerze, popraw swój kod! - czyli dwa słowa o pylint - jaktestowac.pl

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *