On lance un pip install requests sur une machine de dev, tout fonctionne. Trois mois plus tard, un second projet réclame une version différente de la même bibliothèque, et le premier script plante sans prévenir. Ce scénario suffit à poser la question : faut-il systématiquement coupler pip à un environnement virtuel Python avant d’installer quoi que ce soit ?
PEP 668 et pip sur Linux récent : le système qui refuse vos installations
Sur les distributions Linux récentes (Ubuntu 24.04, Debian 12 et leurs dérivées), pip refuse désormais d’écrire dans l’environnement Python système lorsque celui-ci est marqué comme externally managed. Ce verrou découle de la PEP 668.
A découvrir également : Comment corriger automatiquement les erreurs les plus fréquentes de ggvtrad ?
Concrètement, un pip install global renvoie une erreur explicite et suggère de créer un venv. L’option --break-system-packages existe pour contourner cette protection, mais les sources récentes la présentent comme un pis-aller à éviter. Créer un environnement virtuel est la réponse recommandée, pas un simple conseil de confort.
Sur macOS et Windows, le verrou PEP 668 n’est pas activé par défaut. On peut toujours installer globalement. Ça ne veut pas dire qu’on devrait : les risques de conflit de dépendances restent identiques, seul le garde-fou système manque.
A voir aussi : Pourquoi 192.168.1..168 s'affiche dans votre navigateur au lieu de la page routeur ?
Conflit de dépendances pip : le cas concret qui casse un projet
Prenons deux projets côte à côte. Le premier utilise une bibliothèque en version 1.x, le second exige la version 2.x de cette même bibliothèque. Sans isolation, pip écrase la version précédente à chaque installation. L’un des deux projets finit en erreur.
Un environnement virtuel (venv, virtualenv ou équivalent) crée un dossier autonome contenant son propre interpréteur Python et ses propres packages. Chaque projet dispose de son arbre de dépendances sans interférer avec les autres.
On entend parfois que pour un script ponctuel, un simple pip install global suffit. C’est vrai dans un contexte isolé : un notebook de data science sur un poste personnel, un script jetable. Dès que le script devient un projet partagé ou déployé ailleurs, le fichier requirements.txt généré depuis un venv garantit la reproductibilité.
Utiliser pip sans activer le venv : une option méconnue
L’activation d’un environnement virtuel (la commande source .venv/bin/activate ou .venv\Scripts\activate sous Windows) modifie le PATH du terminal. On peut s’en passer.
Appeler directement l’interpréteur du venv fonctionne tout aussi bien :
.venv/bin/python -m pip install requestsinstalle le package dans le venv sans activation préalable- Cette approche est utile dans les scripts CI/CD ou les Makefiles, où l’activation de shell n’a pas de sens
- Elle évite aussi les confusions quand on jongle entre plusieurs terminaux ouverts sur des projets différents
L’activation reste pratique au quotidien pour raccourcir les commandes, mais elle n’est pas un prérequis technique. Pointer vers le bon interpréteur Python suffit pour que pip écrive au bon endroit.
venv, virtualenv ou uv : quel outil avec pip en 2025
Le module venv est intégré à Python depuis la version 3.3. Il couvre la majorité des besoins sans installation supplémentaire. virtualenv reste disponible et offre quelques options avancées (choix de la version Python, création plus rapide), mais pour un usage courant, venv fait le travail.
Les outils plus récents comme uv gagnent du terrain comme alternative intégrée à pip et venv. Ils gèrent à la fois l’installation de packages, la création d’environnements et parfois même les versions de Python, dans un seul binaire. Les retours varient sur ce point selon les équipes, mais la tendance va clairement vers la simplification de la chaîne d’outils.
Un récapitulatif rapide des situations :
- Projet de développement classique :
python -m venv .venvpuis pip dans le venv, c’est le standard - Équipe qui veut un outil unique et rapide : uv remplace pip + venv dans un workflow unifié
- Script ponctuel sur poste personnel : une installation globale reste acceptable, tant qu’on ne distribue pas le code
- Serveur dédié à une seule application (serveur web Django par exemple) : l’installation globale peut se justifier si on traite les mises à jour pip comme des mises à jour système testées en amont
Commandes venv et pip : le workflow minimal pour démarrer
On part d’un dossier projet vide. Voici la séquence qu’on utilise sur la plupart des postes :
python -m venv .venv crée le dossier .venv avec un interpréteur isolé. Sous Windows, on active avec .venv\Scripts\activate, sous Linux et macOS avec source .venv/bin/activate. Une fois dans le venv, pip install écrit exclusivement dans cet environnement.
Pour figer les dépendances, pip freeze > requirements.txt génère la liste exacte des packages installés avec leurs versions. Un collègue ou un serveur de production peut reproduire l’environnement avec pip install -r requirements.txt dans son propre venv.
Ajouter le dossier .venv au fichier .gitignore évite de versionner plusieurs centaines de mégaoctets de bibliothèques. Seul le fichier requirements.txt entre dans le dépôt.
Pour quitter l’environnement, la commande deactivate restaure le PATH initial du terminal. Le dossier .venv reste sur le disque, prêt à être réactivé.
La réponse courte à la question de départ : oui, dans la grande majorité des cas, coupler pip à un environnement virtuel protège vos projets et votre système. Les rares exceptions (script jetable, serveur mono-application) confirment la règle plus qu’elles ne l’invalident. Sur les distributions Linux récentes, le système vous y oblige de toute façon.
