Piszę aplikację opartą na Twisted. Niestety, w standardowej dystrybucji jest dość stara wersja. Zainstalowanie nowszej nie stanowi problemu, bądź co bądź to tylko easy_install
. Podobnie łatwo mogę pociągnąć najnowsze Pylons-y, Mako czy SQLAlchemy. I tak dalej.
Stop następuje po paru miesiącach, gdy okazuje się, że sam już nie wiem jakie wersje i czego mam poinstalowane, jakiś program użytkowy z standardowej dystrybucji nie chce działać, bo najnowsza wersja którejś z bibliotek zmieniła API, do tego mam dwie aplikacje, z których jedna powinna działać na WebHelpers 0.3.2 a druga na 0.6.
Co z tym zrobić?
Wszystkie powyższe problemy rozwiązuje VirtualEnv. Możemy instalować dodatkowe moduły nie zaśmiecając podstawowej instalacji pythona, możemy wykorzystywać różne wersje tej samej biblioteki w zależności od projektu, możemy łatwo przełączać się między oficjalną wersją, a developowanym niestabilnym kodem. Do tego, możemy to wszystko robić bez uprawnień administratora.
Przygotowanie
Zakładam, że interpreter pythona mamy już zainstalowany. Musimy zadbać o zainstalowanie w nim stosunkowo nowego SetupTools. Jakaś spaczkowana wersja jest niemal zawsze dostępna, ale bywa archaiczna. Potrzebujemy wersji 0.6c8 (lub nowszej), przy starszych może nie działać instalowanie modułów zależnych. Tak więc, jeśli zainstalowane jest starsze SetupTools, namawiamy administratora na polecenie:
$ easy_install -U SetupTools
a jeśli nie mamy ich w ogóle, na ściągnięcie i uruchomienie pliku ez_setup.py.
Sprawdzenie wersji:
$ python >>> import setuptools >>> print setuptools.__version__
Drugie polecenie administratora to instalacja samego VirtualEnv (niemal nigdzie nie jest dostępne w paczkach):
$ easy_install -U virtualenv
Na tym kończymy zaśmiecanie instalacji. Całe to przygotowanie jest jednorazowe.
Jeśli uzyskanie praw administratora jest niemożliwe, a SetupTools mamy zainstalowane, możemy ręcznie ściągnąć plik
virtualenv.py
, zapisać go gdziekolwiek i zastąpić w dalszej instrukcji wszelkie wystąpieniapython -m virtualenv
przezpython /sciezka/do/virtualenv.py
Tworzenie środowiska
Wirtualne środowisko tworzymy wołając:
$ python -m virtualenv ~/PythonEnvs/DjangoTestEnv
Parametr jest nazwą (nieistniejącego jeszcze) katalogu w którym wirtualne środowisko powstanie. Lokalizacja może być dowolna, możemy mieć dedykowany katalog na wszystkie środowiska, możemy tworzyć je w podkatalogach poszczególnych projektów. W tym katalogu będą zapisywane wszystkie biblioteki i skrypty instalowane w środowisku.
Wirtualne środowisko stworzone jak wyżej widzi biblioteki zainstalowane systemowo. Alternatywna forma:
$ python -m virtualenv --no-site-packages $HOME/PythonEnvs/WbReleaseTest
sprawia, że python
będzie widział tylko moduły zainstalowane w środowisku i bibliotekę standardową, systemowe site-packages
będzie ignorowane. Ta forma jest przydatna zwłaszcza gdy np. chcemy przetestować kompletność jakiejś procedury instalacyjnej czy dystrybucyjnej.
Po powstaniu środowiska kontrolnie zaczynamy od:
$ ~/PythonEnvs/DjangoTestEnv/bin/easy_install -U SetupTools
Wykorzystywanie wirtualnego środowiska
Do tak powstałego środowiska możemy się odnosić na trzy sposoby.
Po pierwsze, pakiety instalowane przy pomocy easy_install z katalogu środowiska są instalowane w tymże katalogu:
$ ~/PythonEnvs/PylonsTestEnv/bin/easy_install PasteScript
zainstaluje:
- biblioteki w
~/PythonEnvs/PylonsTestEnv/lib
- skrypt
paster
w~/PythonEnvs/PylonsTestEnv/bin
Po drugie, skrypty uruchamiane przy pomocy interpretera z tego katalogu będą z tych bibliotek korzystać:
$ ~/PythonEnvs/PylonsTestEnv/bin/python moj_skrypt.py
(~/PythonEnvs/PylonsTestEnv/bin/python
można też skonfigurować jako ścieżkę do interpretera pythona w środowisku IDE czy jakimś serwerze aplikacji)
Wreszcie, przy dłuższej pracy w danym środowisku z jednego terminala, można wydać polecenie
$ . ~/PythonEnvs/PylonsTestEnv/bin/activate
(uwaga na kropkę) które skoryguje PATH
(a także pewne inne zmienne środowiskowe) pozwalając na proste uruchamianie python
, easy_install
itp. Do tego, dla oznaczenia faktu korzystania z wirtualnego środowiska, prompt zostanie zmodyfikowany, np. tu przyjmie postać:
(PylonsTestEnv):~/src$
Komenda
$ deactivate
usuwa wszystkie efekty wcześniejszego activate
.
Windows
Opisywana technika działa też pod Windows, w niemal identycznej formie (pojawia się katalog scripts
a nie bin
, activate
jest skryptem .bat
który po prostu uruchamiamy).