Dans l'article précédent, nous avons vu comment déployer une application web Python avec Nginx et uWSGI, en prenant l'exemple de l'application 0bin. En conclusion, nous avions cependant noté que cette application était livrée avec toutes les bibliothèques nécessaires, ce qui est rarement le cas. En général, les applications sont plutôt livrées avec un fichier requirements.txt contenant la liste des dépendances à installer avec pip.
L'une des grandes forces de Python, c'est de permettre d'installer ces dépendances dans un environnement limité à l'application, pour que chaque application ait exactement la bonne version de chaque bibliothèque dont elle a besoin. Cet environnement est nommé virtualenv. Voyons comment le mettre en place et l'utiliser dans uWSGI.
Virtualenv
Prenons cette fois ci l'application microblog, issue du formidable tutorel Flask de Miguel Grinberg.
sudo mkdir -p /srv/www/sysnove.fr
sudo chown www-data:www-data /srv/www/sysnove.fr
sudo -u www-data git clone https://github.com/miguelgrinberg/microblog.git /srv/www/sysnove.fr/microblog
Passez toute la configuration, vous avez donc votre application Python dans /srv/www/sysnove.fr/microblog, et il faut maintenant installer ses dépendances, listées dans le fichier requirements.txt.
Babel==0.9.6
Flask==0.9
Jinja2==2.6
# … etc, etc
La méthode la plus simple consiste à installer ces dépendances globalement au système, en utilisant la commande sudo pip install -r requirements.txt. Mais comme on est pas des sauvages et qu'on a peut-être une autre application qui dépend de Flask 0.8, on va plutôt profiter de la puissance de Python et installer ces dépendances dans un Virtualenv dédié à cette application. Ça se fait comme ça :
sudo su www-data # On fait tout ça en temps qu'utilisateur www-data
cd /srv/www/sysnove.fr/microblog
virtualenv venv --no-site-package # Création du virtualenv isolé du système
source venv/bin/activate # On se place "dans" le virtualenv
pip install -r requirements.txt # On installe les bibliothèques localement au virtualenv
deactivate # Et on quitte le virtualenv
Vous avez désormais un répertoire venv/ à la racine de votre application. Il contient notamment les bibliothèques installées, un lien vers l'exécutable Python, une version de pip et setuptools, et quelques scripts permettant de l'activer ou de le désactiver. Par défaut, il utilisera la version de python par défaut de votre système, /usr/bin/python, mais vous pouvez aussi préciser une version à la création du Virtualenv :
virtualenv venv --no-site-package -p python3.3 # par exemple
uWSGI
La configuration uWSGI ressemble beaucoup à celle de l'article précédent, à ceci près qu'il va falloir préciser le chemin du Virtualenv :
[uwsgi]
plugins = python
chdir = /srv/www/sysnove.fr/microblog
module = app
callable = app
virtualenv = /srv/www/sysnove.fr/microblog/venv
Et pour Nginx, je vous renvoie à l'article précédent.
Conclusion
Ces Virtualenv, très utilisés par les développeurs Python pour contrôler les versions des bibliothèques dans leur environnement de développement, sont aussi extrêmement pratiques en administration système pour garantir que chaque application tourne dans l'environnement exact dont elle a besoin.
À y réfléchir, c'est même parfaitement logique. Sous Debian, par exemple, les versions des paquets présents dans les dépôts sont censées assurer une cohérence dans les dépendances entre ces paquets. Mais dès que vous commencez à installer des applications depuis d'autres sources, comme c'est le cas pour les applications web, vous ne pouvez plus vous permettre de piocher vos dépendances dans le système de gestions de paquets, car elles sont susceptibles d'être mises à jour à tout moment et de casser votre application qui, elle, n'a pas été mise à jour. Les Virtualenv sont la solution parfaite à ce problème.
Vous pouvez même décider de la version de Python à utiliser. N'hésitez pas à tester, vous serez surpris de constater le nombre d'applications compatibles avec Python 3.3 !
