Un beau jour de printemps, durant une mission chez un client, on m’a demandé d’installer une version précise d’une librairie pour pouvoir exécuter un projet sur mon poste. Pour simplifier, disons qu’il s’agissait de la librairie « malib » en version 1.2.2.
Facile, je sais comment installer une version précise, il suffit de taper la commande suivante :
> pip install malib==1.2.2
Pip m’installe la librairie « malib » en version 1.2.2. Le projet s’exécute correctement. J’en modifie une partie pour intégrer des retours client puis je l’envoie en ligne et je passe à autre chose…
Quelques semaines plus tard, après avoir travaillé sur d’autres projets on me fait à nouveau des retours sur ce logiciel nécessitant malib en version 1.2.2.
Je le l’ouvre donc dans mon IDE favori, je le lance… Et là surprise, il ne fonctionne plus !
Il me donne simplement l’erreur suivante :
malib.mafonction does not exist
Etrange, c’est la librairie que j’ai installée l’autre jour, elle fonctionnait bien la dernière fois pourtant… Quoique je me souviens l’avoir mise à jour pour l’utiliser dans un autre projet. Ses fonctionnalités auraient changé ? Allons voir sur Google.
La librairie malib a changé, les fonctionnalités de la version 1.2.2 ont évolué. Si vous souhaitez utiliser
L’un des premiers posts StackOverflowmalib.mafonction, vérifiez que vous êtes bien en présence de malib 1.2.2 et non pas la dernière version.
D’accord, cette piste est plausible. J’ai effectivement le souvenir d’avoir mis à jour malib pour travailler sur un autre projet. Vérifions ça avec la commande pip freeze qui nous liste tous nos packages installés et leurs versions :
> pip freeze
…
malib==2.0.0
…Effectivement, elle a bien changé. Elle est désormais en version 2.0.0. Que faire…
Si je la réinstalle en version 1.2.2, mes autres projets ne vont plus fonctionner, mais si je ne fais rien, je ne pourrais pas travailler sur celui-ci.
Virtualenv à la rescousse
La solution à ce scénario — que l’on rencontre très vite si on est amené à travailler sur plusieurs projets — ce sont les environnements virtuels.
Un environnement virtuel, c’est ni plus ni moins qu’un dossier dans lequel on met une copie vierge (sans packages) de python et de pip.
Ensuite, on dit à notre terminal : « Quand je tape python ou pip, tu dois utiliser les copies de ces programmes dans mon dossier plutôt que le python global et le pip global« . Ainsi, si on installe des packages, ils n’iront pas polluer notre python global. A la place, ils iront se mettre dans notre dossier local.
Rassurez vous, on ne va pas le faire à la main. Heureusement, des gens meilleurs que nous ont déjà automatisé la démarche… La librairie virtualenv fait exactement ça. Installons la :
> pip install virtualenvSi tout s’est bien passé, nous pouvons désormais utiliser la commande virtualenv dans notre console. Pour créer un environnement virtuel (le dossier et tous ses raccourcis qu’on a vu au dessus), on tapera :
Si tout s’est bien passé, nous pouvons désormais utiliser la commande virtualenv dans notre console. Pour créer un environnement virtuel (le dossier et tous ses raccourcis qu’on a vu au dessus), on tapera :
> virtualenv mon_env« mon_env » est en fait le nom de notre environnement virtuel, ainsi que le nom du dossier dans lequel il va aller s’installer. Vous pouvez remplacer « mon_env » par ce que vous voulez. Une pratique commune est de l’appeler venv: virtualenv venv.
Cette commande fait exactement ce qu’on a vu plus haut. Elle créée un dossier appelé comme vous lui avez demandé (venv ou mon_env dans les deux exemples ci-dessus). Ensuite elle y place une copie de python et de pip vierges. Enfin, dans le dossier venv/Scripts vous trouverez un script pour « activer » votre environnement virtuel. Ce script est très simple : il va remplacer les programmes python et pip globaux par ceux présents dans votre dossier. Pas d’inquiétude, cette action est réversible. Soit en tapant la commande deactivate soit simplement en fermant la console.
# sur linux > ./venv/Scripts/activate # sur windows > ./venv/Scripts/activate.bat
Pour les experts, il existe aussi dans ce dossier un script pour l’activer sur Powershell, fish, zsh et d’autres terminaux exotiques.
Nous voilà donc désormais avec un environnement virtuel activé. Testons ses effets :
> pip freeze ...
La commande pip freeze ne nous affiche rien. Cela signifie qu’on est en présence d’un interpréteur python vierge. Nous pouvons donc installer n’importe quelle librairie, elle sera simplement ajoutée à cet environnement virtuel. Une fois qu’on change de projet, il suffit de fermer son terminal ou de taper la commande deactivate pour désactiver l’environnement virtuel et revenir à la normale.
Bonus
En bonus, on va voir comment utiliser la commande pip freeze à notre avantage.
Pour cela, il faut déjà être conscient du problème. Que feriez vous si on vous confiait un nouvel ordinateur sur lequel vous devriez relancer votre projet, ou si quelqu’un d’autre souhaitait le faire tourner sur son poste ?
Sur la machine hôte, vous devriez avoir à disposition toutes les librairies dont dépend votre application, avec leur version exacte.
Fort heureusement, il n’est pas nécessaire de faire une archive .zip de votre environnement virtuel à chaque fois que vous partagez votre projet. A la place, on utilise la commande pip freeze > requirements.txt . Notez qu’on passe par l’opérateur > pour forcer la sortie de notre commande pip freeze à aller directement dans le fichier requirements.txt à la place de l’afficher en console.
Ainsi, pour installer les bonnes librairies avec les bonnes versions, on tapera les commandes suivantes :
> virtualenv venv > ./venv/scripts/activate (venv) > pip install -r requirements.txt
On dit au pip de notre environnement virtuel d’installer les librairies contenues dans le fichier requirements.txt.
Et voilà, vous savez ce qu’il y a a savoir pour bien débuter avec les environnements virtuels !