5.4 KiB
| Title | Date | Tags |
|---|---|---|
| Les environnements virtuels | 2013-08-03 | env, python, libs, virtualenv |
L'objectif des environnements virtuels est de pouvoir créer un bac à sable à l'intérieur d'un système, avec ses librairies, ses compilateurs, interpréteurs et fichiers binaires propres, sans que tout ce petit monde n'empiète sur le système existant.
En gros et grâce à cela, il est possible d'avoir un OS avec un interpréteur Python en 2.7 standard, et d'avoir une infinité d'environnements virtuels, chacun ayant son petit compilateur/interpréteur perso. Bref, ça crée une bonne couche d'isolation entre un truc qui fonctionne (l'OS), un truc qui devrait fonctionner (l'environnement de développement), et un truc qui fonctionne (normalement), l'application en production.
Virtualenv
Les dépendances principales (pour un environnement de développement en Python) sont:
- pip
- virtualenv
- virtualenv-wrapper
Auquel cas pip ne serait pas disponible pour votre distribution (genre celle de Microsoft), il est toujours possible de passer d'abord par l'installation d'easy_install, pour ensuite installer pip grâce à la commande easy_install pip. Ceci n'est normalement utile que dans le cas de Python 2.x: la version 3.4 inclut pippar défaut.
Personnellement, je préfère utiliser ces packages s'ils sont directement disponibles depuis votre gestionnaire préféré. Cela permet de maintenir les outils de gestion à jour, en même temps que les autres librairies système. En gros, si j'installe virtualenv avec pip, rien ne me dit qu'il sera correctement mis-à-jour; par contre, si je l'installe avec yum et qu'une correction/nouvelle fonctionnalité est apportée, elle sera directement intégrée au système avec un petit yum update.
Une fois que tout est installé, le fonctionnement est assez simple:
La création d'un nouvel environnement se fait grâce aux commandes suivantes:
virtualenv <return of the env>
virtualenv --system-site-packages <a new env> # pour disposer des dépendances déjà installées sur l'hôte
Après cela, il faut encore activer l'environnement, grâce à la commande source path/to/my_new_virtualenv/bin/activate. Pour sortir de l'environnement, il suffit d'utiliser la commande deactivate (qui se trouve dans le path, du coup).
Une fois qu'on est dedans, il faut encore activer l'environnement, grâce à la commande source path/to/my_new_virtualenv/bin/activate. Pour sortir de l'environnement, il suffit d'utiliser la commande deactivate (qui se trouve dans le path, du coup).
Une fois qu'on est dans ce nouvel environnement, les dépendances iront se placer au bon endroit (et ne pourriront donc pas le système hôte).
Virtualenvwrapper
(De nouveau, s'il est dispo dans les dépôts du système, servez-vous). Le principe de virtualenv wrapper est simplement d'ajouter une gestion centralisée pour vos environnements virtuels.
La première étape est d'ajouter deux lignes dans votre fichier .bashrc (ou n'importe quel fichier qui est lancé au démarrage de votre session):
export WORKON_HOME=~/Sources/
source /usr/bin/virtualenvwrapper.sh
La première ligne va simplement spécifier l'emplacement où se trouveront tous les environnements virtuels; la seconde donne le chemin vers le script virtualenvwrapper.sh.
Dès que le fichier .bashrc sera à nouveau lu, les scripts de gestion des environnements seront créés à l'emplacement défini ci-dessus :
virtualenvwrapper.user_scripts creating ~/Sources/initialize
virtualenvwrapper.user_scripts creating ~/Sources/premkvirtualenv
virtualenvwrapper.user_scripts creating ~/Sources/postmkvirtualenv
virtualenvwrapper.user_scripts creating ~/Sources/prermvirtualenv
virtualenvwrapper.user_scripts creating ~/Sources/postrmvirtualenv
virtualenvwrapper.user_scripts creating ~/Sources/predeactivate
virtualenvwrapper.user_scripts creating ~/Sources/postdeactivate
virtualenvwrapper.user_scripts creating ~/Sources/preactivate
virtualenvwrapper.user_scripts creating ~/Sources/postactivate
virtualenvwrapper.user_scripts creating ~/Sources/get_env_details
virtualenvwrapper.user_scripts creating ~/Sources/premkproject
virtualenvwrapper.user_scripts creating ~/Sources/postmkproject
virtualenvwrapper.user_scripts creating ~/Sources/prermproject
virtualenvwrapper.user_scripts creating ~/Sources/postrmproject
Les commandes sont plus sympas que pour la version 'simple':
- mkvirtualenv
- cpvirtualenv
- rmvirtualenv
Une fois qu'un environnement est accessible (en utilisant une première fois mkvirtualenv pour le créer), on peut l'activer avec la commande workon <environnement name> (et toujours utiliser deactivate pour en sortir). Plus besoin de retrouver le chemin complet vers l'environnement pour l'activer, puisqu'on se base sur une variable d'environnement définie dans le fichier .bashrc.
L'autre petit truc sympa, c'est que l'activation du wrapper crée un ensemble de scripts dans le dossier indiqué dans le fichier .bashrc, ce qui permet de créer des scripts à exécuter lors d'une action particulière. Par exemple avant ou après l'activation d'un environnement existant, lors de la suppression, lors de la copie, juste après avoir créer un environnement... Au choix. C'est complet et facile à faire :)