I když Python jako jazyk existuje dlouho, na webu nemá valného zastoupení. Když chcete pythoní web zahostovat na nějakém serveru, kde se tomu správce věnuje, řešení si najdete, ale jelikož nabídka věrně kopíruje poptávku, široký výběr jako u PHP mít nebudete. A přitom má Python proti PHP tolik krásných možností, jak propojit aplikaci s počítačem uživatele a jak se postarat o její pohodlí.
Python je jazyk, ve kterém je možná víc webových frameworků než build-in funkcí a není dlouhodobě udržitelné, aby na serveru bylo jedno pythoní prostředí, které bude společné pro všechny. Proto má Python nástroje, které dávají administrátorům pomyslný francouzský klíč, kterým lze nastavit každé sedadlo v autobuse do polohy, přesně vyhovující aplikaci, jenž na něm bude sedět. Navíc nejen prostředí knihoven může být rozhodující, ale samozřejmě také verze samotného Pythona. Některé komplexní frameworky řešící vše od ORM po testy se nepřepíší do Pythonu 3.x přes noc, ale to neznamená, že jiné nového Pythona nepodporují a ztratit i jen jediného platícího uživatele kvůli verzi interpretu minimálně zamrzí. Podobně můžete dopadnout i sami, pokud vyvíjíte aplikace několik let a na každý další projekt použijete sice stejný framework, ale jiné verze, dřív nebo později narazíte na problém a zjistíte, že změna spolehlivě fungujícího kódu je drahá.
Pěkným příkladem je třeba framework Django, který vychází v nové verzi jednou či dvakrát do roka nebo ještě možná méně stabilní ORM Elixir. Každá nová verze těchto projektů přinese pár nekompatibilit, které se postupně načítají, až se dostanete do bodu, kdy není možné aplikaci upravit tak, aby běžela na stejném základu jako aplikace dokončená včera. Na serveru jednoduše musí běžet více verzí stejného softwaru, ať už jsou na něm jen vaše aplikace nebo i jiných uživatelů.
Dva hadi a více
Python je momentálně udržován ve dvou větvích 2.x a 3.x. V době psaní tohoto článku jde konkrétně o verze 2.7.1 a 3.2. Pro jejich kompilaci není potřeba nic speciální a jelikož se Makefile chová vcelku rozumně, není vyloženě potřeba se trápit s vytvářením balíčků (i když je to lepší). Pro kompilaci zdrojových kódu budeme potřebovat GCC a pár knihoven, které už pravděpodobně ve svém systému máte. Téměř na čistém Debianu si konfigurační skript na žádnou chybějící knihovnu nebo hlavičkové soubory nestěžoval.
Zdrojové kódy najdeme samozřejmě na domovské stránce Pythonu v sekci Download. Doporučuji stahovat „compressed source tarball“.
$ aria2c http://www.python.org/ftp/python/2.7.1/Python-2.7.1.tgz
$ tar xf Python-2.7.1.tgz
$ cd Python-2.7.1 Pokud jste ještě na svém systému nikdy nic nekompilovali, tak správný balíček, bez kterého se neobejdete, je v distribucích založených na Debianu, je build-essential. V něm jsou základní nástroje, které v některých případech plně postačují.
Na kompilaci stačí svatá trojice configure, make, make install, ale u konfiguračního skriptu byste se měli podívat, co skrývá volba –help a případně mu předat nějaké další parametry.
$ ./configure --prefix=/opt/python27/ --enable-ipv6 --with-threads --enable-shared
$ make Zdrojové kódy mají jen 14 MB, takže kompilace netrvá dlouho ani na pomalejším stroji. Pro hrubou představu uvádím časy jednotlivých kroků ze svaté trojice na mém Athlonu X2 4000+:
# configure
real 0m36.497s
user 0m14.460s
sys 0m8.340s
# make
real 2m52.675s
user 2m22.280s
sys 0m12.480s
# make install
real 0m19.239s
user 0m12.780s
sys 0m1.520s Pokud se po spuštění čerstvého Pythonu objeví něco podobného,
$ /opt/python27/bin/python
/opt/python27/bin/python: error while loading shared libraries: libpython2.7.so.1.0: cannot open shared object file: No such file or directory Je potřeba linkeru říci, že má hledat knihovny i na novém místě.
# echo "/opt/python27/lib" > /etc/ld.so.conf.d/python.conf
# ldconfig Virtuální prostředí
Hadi jsou na místě, ale pokud s nimi občas pracujete, tak víte, že bez modulů s nimi bude jen polovina legrace. A to je chvíle, kdy přichází nástroj virtualenv. Jak už bylo zmíněno v minulém článku o hostování Pythonu, virtualenv je skript, který umí vytvořit pythoní virtuální prostředí s vlastními moduly, oddělené od modulů nainstalovaných v systému a samozřejmě i ostatních podobně vytvořených prostředí. Nejedná se o bezpečnostní mechanizmus, ale pouze funkční.
Než vůbec začneme, musíme se postarat o to, aby šly instalovat aplikace. Nejjednodušší je využít Pythona, který je v distribučních balíčcích. V Debianu a Ubuntu si vystačíme s těmito balíčky:
- python-setuptools
- python-pip
- python-virtualenv
Utilitka pip stojí nad setuptools a umožňuje prohledávat repositáře pythoních modulů a instalovat je z něj. Dokáže se postarat i o instalaci konkrétní verze vybraného modulu. Poslední balíček obsahuje virtualenv, který uživatelům umožní vytvářet již několikrát zmíněné vlastní virtuální prostředí. Nebudeme ale předbíhat a nejdříve připravíme nainstalované Pythony. Balíčky, které jsou v seznamu výše, musíme dostat i do nich. První v pořadí musí být setuptools, protože na něm jsou závislé další dva moduly a bez tohoto modulu nepojede ani distribuční pip. Setuptools lze stáhnout z pypi.python.org a nainstalovat jaké kterýkoli jiný modul.
$ tar xf setuptools-0.6c11.tar.gz
$ cd setuptools-0.6c11/
$ /opt/python27/bin/python setup.py install A teď použijeme distribuční pip a nainstalujeme jak jej, tak virtualenv v posledních verzích.
# pip -E /opt/python27/ install pip
# /opt/python27/bin/pip install virtualenv Všimněte si, že v případě virtualenv jsme už mohli použít pip z námi zkompilovaného Pythona 2.7. Pokud instalujete zároveň i Python 3.2, tak proveďte stejné kroky jako u verze 2.7.
Nyní nastal čas vytvořit první virtuální prostředí, oddělené od toho společného systémového. Není to nic složitého a měli bychom začít s parametrem –help u utilitky virtualenv. Nejdůležitější parametr je –no-site-packages, kterým můžeme říci, že se globálními moduly nemají zařazovat do našeho prostředí. Tím naší aplikaci dáme přesně ty verze, na kterých stojí a změny v systému se nepodepíší na jejím fungování. Jdeme tedy na vytvoření virtuálního prostředí.
$ cd
$ mkdir virtualenvs
$ cd virtualenvs
$ /opt/python27/bin/virtualenv --no-site-packages test_ve Když se nyní podíváme do adresáře test_ve, najdeme v něm téměř vše, co Python potřebuje k běhu. Nic nám nyní nebrání nainstalovat si do něj pár knihoven.
$ cd test_ve/
$ bin/pip install django==1.2.5
$ bin/pip install ipython
$ bin/pip install readline
$ bin/pip install psycopg2 Všimněte si výběru konkrétní verze Djanga. Nyní máme virtuální prostředí s názvem test_ve, uložené v ~/virtualenvs/test_ve, které obsahuje jenom ty knihovny, které chceme. K interpretu se dostaneme přes:
$ bin/python Respektive:
$ bin/ipython Pokud chceme mít zkompilovaného Pythona k dispozici po zadání pouhého python do řádky, stačí přidat do souboru ~/.bashrc následující řádek:
export PATH=/opt/python27/bin/:$PATH Samozřejmě můžeme nahradit cestu k adresáři bin, který se nachází ve virtuálním prostředí test_ve.
Podobně můžete postupovat s Pythonem 3.2 s jediným rozdílem. Místo setuptools použijte distribute:
# wget http://python-distribute.org/distribute_setup.py
# /opt/python32/bin/python3 distribute_setup.py Závěr
Ukázali jsme si, jak dostat do systému libovolný interpretr programovacího jazyka Python a zároveň udržet v systému pořádek i bez použití balíčků. Ne všechny distribuce vám umožní nainstalovat poslední vydanou verzi z repositářů, takže je potřeba jim trochu pomoci.
Nyní nám zbývá nakonfigurovat uWSGI, aby se s ním dobře spravovalo více webů najednou a propojit ho kromě Apache s dalšími webovými servery, ale to až někdy příště.
