La commande python -m pip remplace avantageusement l’appel direct à pip dans le terminal. Elle garantit que le gestionnaire de paquets cible le bon interpréteur, ce qui évite les installations croisées quand plusieurs versions de Python coexistent sur la même machine.
Pourquoi pip seul vise parfois le mauvais interpréteur Python
Appeler pip install directement dans le terminal exécute le binaire trouvé en premier dans le PATH. Sur un poste avec Python 3.10 et Python 3.12 installés côte à côte, rien ne garantit que pip.exe pointe vers la version attendue.
Le problème s’aggrave sur les distributions Linux qui maintiennent un Python système séparé du Python utilisateur. Installer un paquet au mauvais endroit peut casser des outils système ou créer des conflits de dépendances invisibles au départ.
La syntaxe python -m pip install lie explicitement pip à l’interpréteur appelé. Si vous lancez python3.12 -m pip install requests, le paquet atterrit dans l’arborescence de Python 3.12, sans ambiguïté.
Le lanceur py sur Windows et la commande py -m pip
Sur Windows, le lanceur py fourni par l’installeur officiel de python.org sélectionne la version de Python voulue. La commande py -3.12 -m pip install cible précisément Python 3.12, même si Python 3.10 est aussi présent.
Ce lanceur est signé et résout un problème fréquent : pip.exe seul peut pointer vers une installation différente de celle affichée par py –list. Nous recommandons de toujours passer par py -m pip sur Windows plutôt que d’appeler pip.exe directement.
Pour vérifier quelle version de pip répond, la commande py -m pip –version affiche à la fois la version de pip et le chemin de l’interpréteur associé. C’est le premier réflexe de diagnostic quand un paquet semble installé mais reste introuvable à l’import.
ensurepip, get-pip.py et distributions Linux : réamorcer pip quand il manque
Les installeurs binaires officiels de Python embarquent pip par défaut. En théorie, il suffit d’installer Python pour disposer de pip. En pratique, plusieurs scénarios cassent cette logique.
- Certaines distributions Linux retirent volontairement pip du paquet Python de base. Sur Debian et ses dérivés, il faut installer le paquet python3-pip séparément via apt.
- Le module ensurepip permet de réamorcer pip sans connexion réseau, à partir des fichiers wheel déjà présents dans l’installation Python. La commande python -m ensurepip –upgrade restaure pip localement.
- Si ensurepip n’est pas disponible (cas de certains environnements CI ou de conteneurs allégés), le script get-pip.py téléchargé depuis le site officiel de pip reste la solution de secours. Il s’exécute avec python get-pip.py et installe la dernière version stable.
Sur Arch Linux et d’autres distributions rolling release, pip est parfois marqué comme géré par le système. Le drapeau –break-system-packages contourne cette protection, mais un environnement virtuel reste la voie propre.
Environnement virtuel et pipx : isoler les installations pip
Installer des paquets directement dans le Python système crée des conflits de versions dès que deux projets demandent des dépendances incompatibles. L’environnement virtuel résout ce problème en cloisonnant chaque projet.
La création se fait en une commande : python -m venv mon_env. L’activation (source mon_env/bin/activate sur Linux/macOS, mon_env\Scripts\activate sur Windows) redirige pip vers le répertoire isolé. Toute installation ultérieure reste confinée à cet environnement.
Pour les outils en ligne de commande (black, ruff, cookiecutter), pipx isole chaque outil dans son propre environnement tout en plaçant l’exécutable sur le PATH global. La distinction est nette : pip gère les bibliothèques d’un projet, pipx gère les outils globaux sans polluer le Python système.
Résoudre les erreurs courantes de pip install
L’erreur « externally-managed-environment » apparaît sur les distributions récentes qui protègent le Python système. Elle signifie que pip refuse d’installer un paquet hors d’un environnement virtuel. La solution n’est pas de forcer l’installation avec –break-system-packages, mais de créer un venv.
L’erreur « No matching distribution found » indique souvent un décalage entre la version de Python et la compatibilité du paquet. Vérifier la page du paquet sur PyPI permet de confirmer les versions supportées.
- Permission denied : sur Linux/macOS, ne pas utiliser sudo pip install. Préférer –user pour une installation locale ou, mieux, travailler dans un venv.
- pip: command not found : le PATH ne contient pas le répertoire de pip. Relancer avec python -m pip résout le problème dans la majorité des cas.
- Version de pip obsolète : python -m pip install –upgrade pip met à jour le gestionnaire lui-même. Une version trop ancienne peut échouer à résoudre certaines dépendances.
Récapitulatif des commandes pip à connaître
| Action | Commande |
|---|---|
| Installer un paquet | python -m pip install nom_paquet |
| Mettre à jour pip | python -m pip install –upgrade pip |
| Lister les paquets installés | python -m pip list |
| Vérifier la version de pip | python -m pip –version |
| Installer depuis un fichier requirements | python -m pip install -r requirements.txt |
| Désinstaller un paquet | python -m pip uninstall nom_paquet |
Adopter systématiquement la forme python -m pip (ou py -m pip sur Windows) plutôt que pip seul reste le changement de pratique le plus rentable. Combiné à un environnement virtuel par projet et à pipx pour les outils CLI, ce workflow élimine la quasi-totalité des problèmes d’installation que nous observons en production.
