Installing Python with pip : différences entre pip, pip3 et pipx

On lance pip install requests sur une machine avec Python 2 et Python 3 installés, et le paquet atterrit dans le mauvais interpréteur. Le lendemain, un pip install black exécuté sans environnement virtuel casse une dépendance système. Ces deux situations, banales, résument pourquoi la distinction entre pip, pip3 et pipx n’est pas un détail théorique mais une source concrète de bugs.

python -m pip : la commande qui évite les erreurs d’interpréteur

Sur un système où plusieurs versions de Python coexistent (un serveur Linux avec Python 2.7 encore présent, un poste de dev avec Python 3.11 et 3.12), taper pip ou pip3 dans le terminal ne garantit pas grand-chose. Le binaire appelé dépend de l’ordre des chemins dans le PATH, et on se retrouve régulièrement à installer un paquet dans un environnement qu’on ne visait pas.

A découvrir également : Comment configurer son premier accès ENT Paris Classe Numérique authentification ?

Privilégier python -m pip plutôt que pip ou pip3 règle le problème à la source. Cette syntaxe lie explicitement l’installation au python que vous invoquez. Si vous travaillez avec Python 3.12, la commande devient python3.12 -m pip install requests, sans ambiguïté.

Les guides de bonnes pratiques des distributions récentes et de la documentation Python reprennent désormais cette recommandation. Les résultats de recherche se concentrent souvent sur la distinction historique pip/pip3, alors que python -m pip rend cette distinction obsolète dans la plupart des cas d’usage.

A lire aussi : Comprendre Cc et Cci dans les emails : différences et usages pratiques

pip et pip3 : quand la différence compte encore

Historiquement, pip pointait vers Python 2, et pip3 vers Python 3. Sur les systèmes modernes où Python 2 a été retiré, les deux commandes renvoient souvent au même interpréteur. On peut le vérifier avec pip --version et pip3 --version : si les chemins affichés sont identiques, la distinction n’a plus d’effet concret.

Cas où pip3 reste pertinent

Certaines distributions Linux maintiennent encore un Python 2 pour des paquets système hérités. Dans ce contexte, pip peut rester lié à Python 2. Taper pip3 force alors l’utilisation de Python 3, ce qui évite d’installer un paquet dans un environnement obsolète.

Sur macOS, la situation dépend de la méthode d’installation de Python (Homebrew, pyenv, installateur officiel). Les retours varient sur ce point selon les configurations, mais la règle reste la même : vérifier avec --version avant d’installer quoi que ce soit.

L’erreur externally-managed-environment sur Ubuntu et Debian

Depuis Python 3.11 et les versions récentes d’Ubuntu ou Debian, lancer pip install en dehors d’un environnement virtuel déclenche une erreur explicite :

error: externally-managed-environment

Ce n’est pas un bug. Les distributions protègent désormais leur environnement Python système contre les installations sauvages via pip. Installer un paquet avec sudo pip install risquait de casser des outils système qui dépendent de versions précises de bibliothèques Python.

Deux solutions propres existent :

• Créer un environnement virtuel avec python3 -m venv .venv, l’activer avec source .venv/bin/activate, puis utiliser pip install à l’intérieur. C’est la méthode standard pour les projets de développement.
• Utiliser pipx pour les outils en ligne de commande qu’on veut accessibles partout sur la machine, sans toucher à l’environnement système.
• Passer par le gestionnaire de paquets de la distribution (apt install python3-xyz) quand le paquet existe dans les dépôts officiels.

Ne jamais contourner cette protection avec --break-system-packages sauf sur une machine jetable ou un conteneur. Sur un serveur de production, c’est le chemin le plus court vers un système instable.

pipx : installer des outils CLI Python sans polluer le système

pipx résout un problème précis : on veut utiliser un outil en ligne de commande écrit en Python (un formateur de code, un linter, un outil d’infrastructure) sans créer manuellement un environnement virtuel à chaque fois.

pipx crée automatiquement un environnement isolé pour chaque application. Les dépendances de l’outil restent confinées, et le binaire devient accessible globalement via le PATH.

Exemple concret avec Ansible

Des guides d’administration système récents recommandent pipx comme méthode standard pour installer Ansible sur Fedora ou RHEL. La séquence type ressemble à :

sudo dnf install pipx && pipx ensurepath && pipx install --include-deps ansible

Cette approche évite le sudo pip install ansible qui polluait l’environnement système et compliquait les mises à jour. Le même raisonnement s’applique à des outils comme black, httpie, poetry ou ruff.

Ce que pipx ne fait pas

pipx n’est pas un remplacement de pip pour les bibliothèques de développement. Si vous avez besoin de requests, pandas ou numpy dans un projet, c’est pip (dans un venv) qui reste l’outil adapté. pip gère les bibliothèques de projet, pipx gère les outils en ligne de commande.

Choisir entre pip, pip3 et pipx selon le contexte

La logique de décision tient en quelques cas concrets :

• Vous développez un projet Python et avez besoin de bibliothèques (requests, flask, sqlalchemy) : créez un venv, utilisez python -m pip install à l’intérieur.
• Vous installez un outil CLI que vous voulez disponible partout (black, ansible, httpie) : utilisez pipx install.
• Vous êtes sur un système ancien avec Python 2 et 3 : utilisez pip3 ou, mieux, python3 -m pip pour lever toute ambiguïté.
• Vous travaillez dans un conteneur Docker où l’environnement est jetable : pip direct fonctionne, l’isolation est assurée par le conteneur lui-même.

Des outils comme uv (développé par Astral, les créateurs de ruff) commencent à proposer des workflows encore plus intégrés, avec leur propre implémentation de pip et venv. Mais pour la majorité des usages quotidiens, le trio venv + pip + pipx couvre les besoins sans ajouter de complexité.

Le réflexe à garder : ne jamais installer un paquet Python en dehors d’un environnement virtuel sur une machine que vous comptez maintenir. La commande python -m pip dans un venv pour les bibliothèques, pipx pour les outils CLI, et la question pip contre pip3 ne se pose même plus.