3.2pip, environnements virtuels (venv) & gestion de dépendances
L'essentiel en 30 secondes
- Le global mélange tout : deux projets exigeant deux versions d'un même paquet sont impossibles ensemble — chaque projet mérite son environnement isolé.
- Le rituel venv + pip : python -m venv .venv, activer, pip install, pip freeze > requirements.txt — l'interpréteur et pip pointent alors vers le venv.
- Le .venv ne se committe jamais, le requirements toujours : versions figées, reconstruction prouvée par pip install -r — le projet est portable.
Mini-cas filé — Nabil sort de l'enfer des versions
Nabil, data analyst junior à Alger, installe tout en global : son analyse ventes exige une version récente d'une librairie, mais le reporting d'un collègue casse dès qu'il met à jour. Il crée un venv par projet (python -m venv .venv), active, installe, fige avec pip freeze > requirements.txt, ajoute .venv au .gitignore. Supprimé puis reconstruit via pip install -r, chaque projet retrouve exactement ses versions.
Ce même cas revient dans le cours, le schéma, le script et le défi 48h.
1. Le chaos du global et la bulle venv
La force de Python est son catalogue PyPI, installé via pip (pip install pandas). Mais tout installer en global mélange les dépendances de tous les projets : le projet A exige une version, le B une autre — impossible ensemble, c'est l'enfer des dépendances. Dès le deuxième projet, l'isolation est non négociable.
La solution est l'environnement virtuel (venv) : un dossier isolé avec son Python et ses paquets, sans toucher aux autres projets. On le crée (python -m venv .venv), on l'active (Windows : .venv\Scripts\activate ; macOS/Linux : source .venv/bin/activate) — le prompt change, python et pip pointent alors vers le venv. Nabil crée un venv pour l'analyse ventes, un autre pour le reporting : chacun vit sa vie.
2. Figer, partager, reconstruire : requirements.txt
Un venv seul ne suffit pas : il faut le contrat des versions. pip freeze > requirements.txt exporte dépendances et versions épinglées ; pip install -r requirements.txt les réinstalle à l'identique ailleurs. Le dossier .venv ne se committe JAMAIS (volumineux, spécifique à la machine, via .gitignore) ; le requirements.txt TOUJOURS (léger, partageable).
Le test de vérité de Nabil : supprimer le .venv et le reconstruire en une commande — si l'analyse tourne, le projet est portable. Vérifier avec pip list que la librairie est bien dans CE venv, et sélectionner l'interpréteur du .venv dans l'éditeur. Après chaque ajout, on refige pour garder le contrat à jour.
🔎 Exemple concret — Rituel complet du projet isolé
Nabil isole son analyse ventes, puis la reconstruit ailleurs.
python -m venv .venv
.venv\Scripts\activate
pip install requests
pip freeze > requirements.txt
deactivateLecture : créer, activer, installer, figer — le requirements devient le contrat.
Leçon : ailleurs, recréer le venv puis pip install -r requirements.txt restaure à l'identique.
Vocabulaire de la section
- pip
- Gestionnaire de paquets de Python : pip install nom télécharge et installe une bibliothèque depuis PyPI dans l'environnement actif.
Exemple simple : Le pip install requests de Nabil dans son venv analyse.
Ce que ce n'est pas : télécharger un ZIP et le poser à la main.
Réflexe : toujours vérifier le venv actif avant pip install.
- PyPI
- Dépôt central des bibliothèques tierces Python : des centaines de milliers de paquets installables.
Exemple simple : Le catalogue où Nabil trouve requests et pandas.
Ce que ce n'est pas : la bibliothèque standard fournie d'office.
Réflexe : standard d'abord, PyPI ensuite.
- Environnement virtuel (venv)
- Dossier isolé avec son Python et ses paquets, propre à un projet, sans interférer avec les autres.
Exemple simple : Le .venv analyse-ventes de Nabil, séparé du reporting.
Ce que ce n'est pas : une installation globale partagée par tous les projets.
Réflexe : un venv par projet, dès le début.
- Activation
- Rendre un venv actif dans le terminal pour que python et pip y pointent (invite modifiée).
Exemple simple : L'activate de Nabil avant chaque session d'analyse.
Ce que ce n'est pas : travailler en oubliant d'activer, donc en global.
Réflexe : activer d'abord, installer ensuite.
- requirements.txt
- Liste des dépendances et versions : pip freeze l'exporte, pip install -r les réinstalle à l'identique.
Exemple simple : Le contrat versionné que Nabil partage à Alger.
Ce que ce n'est pas : le dossier .venv commité dans Git.
Réflexe : figer après chaque ajout, reconstruire pour prouver.
En pratique — Isoler un projet avec venv et pip
- Créez un venv (python -m venv .venv) puis activez-le ; vérifiez que l'invite du terminal a changé.
- Installez une bibliothèque (pip install requests) et vérifiez avec pip list qu'elle est dans CE venv, pas en global.
- Figez avec pip freeze > requirements.txt ; ouvrez le fichier et observez les versions épinglées.
- Désactivez (deactivate), supprimez le venv, recréez-le et réinstallez via pip install -r requirements.txt.
Script prêt à dire — présenter son environnement (30 s)
« Chaque projet a son venv : créé par python -m venv .venv, activé avant toute install, dépendances figées par pip freeze dans requirements.txt versionné, .venv ignoré par Git. Testé par suppression puis pip install -r : reconstruction à l'identique. »
À dire en revue ; montrer le prompt activé et le requirements.
Modèle copier-coller — rituel venv + requirements
python -m venv .venv
.venv\Scripts\activate
pip install requests
pip list
pip freeze > requirements.txt
deactivate
python -m venv .venv
.venv\Scripts\activate
pip install -r requirements.txtIndépendant
Un venv + un requirements figé suffit à partager l'analyse sans friction.
PME à Alger
Nabil duplique le rituel : un venv ventes, un venv reporting, zéro conflit.
Équipe produit
Imposer .venv ignoré + requirements versionné pour des installs identiques partout.
Débutant
Cette semaine : un venv, une install, un freeze, une reconstruction.
✓ Bonnes pratiques
- Créer un venv par projet dès le premier pip install.
- Figer après chaque ajout (freeze) et garder le requirements versionné.
- Reconstruire (supprimer + install -r) pour prouver la reproductibilité.
✗ Pièges fréquents
- Tout installer en global (conflits de versions garantis).
- Commiter le .venv (Mo inutiles, spécifique à la machine).
- Partager un requirements sans versions épinglées (dérive silencieuse).
Points clés à retenir
- pip INSTALLE depuis PyPI dans l'environnement ACTIF — vérifier l'activation d'abord.
- Un VENV isole les dépendances PAR PROJET : fini les conflits de versions.
- requirements.txt (freeze / install -r) rend le projet REPRODUCTIBLE partout.
- .venv JAMAIS commité (.gitignore) ; requirements TOUJOURS versionné, reconstruit pour preuve.
Défi 48h — appliquez demain
Créez 1 venv, installez 1 paquet, figez le requirements, puis reconstruisez via install -r.
- Chaque projet a son venv activé avant install.
- Mon requirements fige les versions exactes.
- Mon .venv est ignoré, ma reconstruction marche.
Questions fréquentes
Pourquoi ne pas tout installer en global, c'est plus simple ?
Parce que deux projets exigeront vite des versions incompatibles d'une même bibliothèque : c'est l'enfer des dépendances. Un venv par projet donne à chacun exactement ce qu'il lui faut et rend le projet partageable à l'identique via requirements.txt.
Faut-il committer le dossier .venv dans Git ?
Non, jamais : volumineux et spécifique à la machine. On l'exclut via .gitignore et on ne partage que requirements.txt — chaque collaborateur recrée son venv par pip install -r.
Que partage-t-on dans Git pour reproduire l'environnement ?