Czym jest virtualvenv ? Virtualenv to wirtualne środowisko, które rozwiązuje problem z nie zawsze kompatybilnymi ze sobą wersjami Pythona. Zadaniem jego jest oddzielenie środowiska Pythonowego dla każdego z projektów z osobna. Oznacza to, że zmiany dokonanie w jednej aplikacji nie wpłyną na zmianę innych. Dzięki temu pozwala rozpocząć pracę z dobrą konfiguracją.
Konfiguracja
Jedyne co należy tutaj zrobić, to wybrać katalog w którym zostanie utworzony virtualvenv. Na potrzebę tutoriala stwórzmy katalog projekt:
mkdir projekt
cd projekt
Można teraz stworzyć własne środowisko wirtualne, polecenie ma następujący format (oczywiście nazwę osworld można zastąpić własną nazwą):
python3 -m venv osworld
Praca z virtualenv
Powyższa instrukcja tworzy katalog o nazwie projekt, zawierający nasze środowisko wirtualne (zbiór katalogów i plików). Środowisko wirtualne uruchamia się za pomocą polecenia:
~/projekt$ source osworld/bin/activate
O tym, że virtualenv jest uruchomiony dowiemy, gdy zobaczymy w swojej konsoli prompt podobny do tego:
(osworld) ~/projekt$
Można zobaczyć że, pojawił się tam prefix osworld, w trakcie pracy ze środowiskiem wirtualnym python będzie automatycznie odnosił się do właściwej wersji. Nie trzeba tam wpisywać python3, wystarczy python. Chcąc wyłączyć środowisko wpisujemy
deactivate
Wszystko zostało przygotowane do tego aby móc zainstalować sobie np. Django. Zajmiemy się tym w następnej części artykułu.
Jeszcze fajniejszy jest virtualenvwrapper, który pozwala zarządzać wieloma środowiskami wirtualnymi i jest dostępny w repozytoriach pakietów np. Debiana. Po instalacji może być konieczne skonfigurowanie zmiennych środowiskowych $WORKON_HOME (katalog z virtualenvami, tj. interpreterami oraz bibliotekami) i $PROJECT_HOME (katalog z projektami tj. kodem źródłowym).
Swoją drogą, należy uważać na przypadek, w którym aktualizujemy Pythona na systemie-gospodarzu. Możliwe bowiem, że w virtualenvie będzie „zalegał” przestarzały interpreter, który będzie chciał korzystać ze zaktualizowanej biblioteki standardowej i „wybuchnie w twarz” z niejasnej przyczyny, np. rzucając ImportError przy ładowaniu niektórych modułów.
W którym miejscu powiedzieliśmy by środowisko używało py2 zamiast py3?