venv en Python : créer un environnement virtuel sans rien installer

Définition

Installer une bibliothèque avec pip la dépose quelque part sur la machine, et par défaut cet endroit est unique : le Python du système. Le problème arrive dès qu'un deuxième projet réclame une version différente de la même bibliothèque. Les deux se disputent le même dossier, la dernière installation écrase la précédente, et l'un des projets se met à échouer sans que rien n'ait changé dans son code.

venv répond à ce problème en donnant à chaque projet son propre dossier : une copie de l'interpréteur et un stock de bibliothèques qui n'appartiennent qu'à lui. C'est le module de la bibliothèque standard qui crée cet environnement virtuel, introduit par la PEP 405 et livré avec Python depuis la version 3.3 : rien à télécharger, rien à installer avant de s'en servir.

La création tient en une commande, suivie d'une deuxième qui active l'environnement.

python -m venv .venv
source .venv/bin/activate
.venv\Scripts\activate

La deuxième ligne vaut pour macOS et Linux, la troisième pour Windows. Une fois l'environnement actif, pip install dépose les bibliothèques dans ce dossier et non plus dans le Python du système, ce qui règle exactement le conflit décrit plus haut. Le nom de l'environnement apparaît alors au début de l'invite du terminal, un repère visuel simple.

Ce que contient réellement le dossier

Venv ne fait rien de sophistiqué : il crée une arborescence de fichiers ordinaires et ajuste un seul réglage.

Activer l'environnement ne fait qu'une chose : placer son dossier d'exécutables en tête du PATH, pour que python et pip désignent ceux de l'environnement plutôt que ceux du système. C'est aussi pour cela qu'on peut se passer entièrement de l'activation : appeler directement .venv/bin/python produit le même résultat, ce que font la plupart des scripts de déploiement.

venv face à ses alternatives

La question revient à chaque nouveau projet : venv suffit-il, ou faut-il un outil plus complet ? La réponse dépend de ce que le projet réclame vraiment.

Pour un exercice, un script, un projet personnel ou un dépôt que d'autres vont cloner, venv suffit et il a l'avantage d'être compris de tout le monde. Un outil plus complet se justifie surtout quand le projet devient un package publié, ou quand plusieurs machines doivent obtenir exactement les mêmes versions.

Les erreurs des premières semaines

La plupart des soucis avec venv tiennent à un oubli facile à commettre au tout début, pas à l'outil lui-même.

Le réflexe qui règle la question tient en deux vérifications : quel Python répond, et où il installe.

which python
python -m pip install requests

Depuis le REPL, lire sys.executable donne la même réponse sans ambiguïté : si le chemin affiché ne passe pas par le dossier du projet, l'environnement n'est pas actif.

Une deuxième erreur consiste à envoyer le dossier .venv dans le dépôt Git. Il pèse lourd, il contient des chemins absolus propres à une machine, et il ne sert à personne d'autre. Ce qui se partage, c'est le requirements.txt, qui permet de reconstruire l'environnement en une commande.

Une troisième erreur vient d'un dossier de projet déplacé ou renommé : les scripts du dossier des exécutables gardent en mémoire le chemin absolu d'origine et cessent de fonctionner. La réparation ne mérite aucun effort : on supprime le dossier et on le recrée.

Quand il ne sert à rien

Un environnement virtuel isole des dépendances les unes des autres. Un script qui n'importe que la bibliothèque standard n'a donc rien à isoler, et créer un venv par réflexe rallonge la mise en route sans rien protéger.

Le cas des conteneurs se discute davantage. Une image Docker ne fait tourner qu'une application, et l'isolation existe déjà au niveau de l'image : beaucoup d'équipes installent alors les bibliothèques directement dans le Python du conteneur. D'autres gardent malgré tout un environnement virtuel, pour que la commande de lancement reste identique en local et en production.

Questions fréquentes

Un par projet, et c'est tout l'intérêt de la démarche. Deux projets peuvent réclamer deux versions incompatibles de la même bibliothèque, et un environnement partagé ramène exactement le problème que venv est censé écarter. Le coût est nul : un environnement se recrée en quelques secondes.

Oui, mais indirectement : venv reprend la version de l'interpréteur qui l'a créé. La commande python3.12 -m venv .venv donne un environnement en 3.12, à condition que cette version soit déjà installée sur la machine. Installer plusieurs versions de Python reste le travail d'un autre outil, comme pyenv.

Non, ce n'est qu'un confort. Appeler .venv/bin/python mon_script.py produit le même résultat sans rien changer au terminal, et c'est la forme retenue dans les tâches planifiées, les conteneurs et les commandes pytest lancées par un outil d'intégration continue.