Le flag pip install -u (alias --upgrade) reste le réflexe de mise à jour pour beaucoup de développeurs Python. Sur les distributions Linux récentes embarquant Python 3.11 ou supérieur, ce réflexe se heurte à un mur : la PEP 668 marque l’environnement système comme externally managed, ce qui bloque ou décourage fortement tout pip install --user global. Comprendre ce changement est le vrai point de départ avant de migrer vers pipenv ou poetry.
PEP 668 et environnement externally managed : pourquoi pip install -u ne suffit plus
Sur Ubuntu 24.04 ou Fedora 38 et au-delà, tenter un pip install -u hors environnement virtuel déclenche une erreur explicite. Le système refuse l’écriture dans le répertoire de paquets Python pour protéger la cohérence des dépendances gérées par le gestionnaire de paquets de la distribution (apt, dnf).
A lire aussi : Les meilleurs émulateurs pour jouer à des jeux Nintendo sur PC
La conséquence directe : installer pipenv ou poetry via pip install –user n’est plus le chemin recommandé sur ces systèmes. La documentation Debian pour pipenv recommande d’ailleurs de créer un virtualenv dédié pour y installer pipenv lui-même, plutôt que de le placer dans l’espace utilisateur global.
Nous observons souvent des développeurs qui contournent le problème avec --break-system-packages. Ce flag existe, mais il désactive une protection utile. Mieux vaut adapter le workflow dès le départ.
A découvrir également : Install pip installer pour les débutants : du téléchargement à l'installation de packages
Installer pipenv et poetry proprement après pip
Deux approches tiennent la route pour poser ces outils sans polluer l’environnement système.
pipx pour isoler les CLI Python
pipx installe chaque outil dans son propre venv isolé tout en rendant la commande accessible globalement. C’est la méthode la plus propre pour installer pipenv, poetry ou tout autre paquet qui fournit une commande CLI.
sudo apt install pipx(oudnf install pipx) puispipx ensurepathpour rendre le répertoire~/.local/binaccessible dans le PATH.pipx install pipenvoupipx install poetry: chaque outil obtient son environnement virtuel privé, sans interférence avec les paquets système.- Mise à jour ultérieure via
pipx upgrade pipenv, qui remplace le réflexepip install -u pipenvsans aucun risque de conflit.
Installation manuelle dans un venv dédié
Si pipx n’est pas disponible sur votre système, créer un venv dédié avec python3 -m venv ~/.local/share/pipenv-venv puis y installer pipenv via pip fonctionne aussi. Un lien symbolique vers ~/.local/bin/pipenv rend la commande accessible. C’est ce que le manpage Debian documente comme alternative.
Fichier lock et dépendances : ce qui change entre pip, pipenv et poetry
Avec pip seul, la gestion des dépendances repose sur un fichier requirements.txt que le développeur maintient manuellement. Aucun mécanisme natif ne verrouille les versions transitives. Un pip install -u sur un paquet peut tirer une nouvelle version d’une dépendance secondaire et casser silencieusement le projet.
Pipenv génère un Pipfile.lock, poetry un poetry.lock : dans les deux cas, chaque dépendance transitive est épinglée avec son hash. La reproductibilité de l’environnement passe de « probable » à « garantie ».
En pratique, la différence la plus structurante entre les deux outils se situe dans la gestion du projet lui-même. Poetry traite le projet comme un paquet publiable (avec un pyproject.toml qui contient les métadonnées de build). Pipenv se concentre sur l’environnement d’exécution sans prétendre packager quoi que ce soit.
Quand choisir pipenv ou poetry
Pipenv convient aux projets applicatifs (API, scripts, services) où personne ne fera jamais pip install mon-projet. Poetry s’impose dès qu’une librairie doit être publiée sur PyPI ou partagée comme paquet installable. Ce n’est pas un choix de confort, c’est un choix d’architecture.
Migrer un requirements.txt existant vers pipenv ou poetry
La migration depuis un projet géré à la main avec pip demande quelques précautions que les tutoriels survolent souvent.
Avec pipenv, un simple pipenv install -r requirements.txt dans le dossier du projet crée le Pipfile et le Pipfile.lock correspondants. Nous recommandons de vérifier ensuite que les versions épinglées dans le lock correspondent bien à celles de l’environnement de production actuel, pas aux dernières versions disponibles.
Avec poetry, la commande poetry init permet de déclarer les dépendances dans pyproject.toml. Il n’existe pas d’import automatique d’un requirements.txt dans poetry (contrairement à pipenv). Chaque dépendance doit être ajoutée via poetry add, ce qui force une résolution propre mais rallonge la migration sur les projets avec de nombreux paquets.
Un piège fréquent : le requirements.txt contient souvent des dépendances installées par pip freeze, donc toutes les dépendances transitives. Importer ce fichier tel quel dans pipenv ou poetry crée un Pipfile ou pyproject.toml surchargé. Mieux vaut n’importer que les dépendances directes et laisser le résolveur reconstruire l’arbre.
Versions de Python et environnements virtuels : le rôle de venv dans la chaîne
Pipenv et poetry créent tous deux des environnements virtuels, mais leur rapport à la version de Python diffère. Pipenv utilise --python 3.11 pour cibler une version spécifique déjà installée sur le système. Poetry lit la contrainte python = "^3.11" dans pyproject.toml et vérifie la compatibilité au moment de la résolution.
Ni l’un ni l’autre n’installe Python. La gestion des versions de Python reste un étage séparé (pyenv, le gestionnaire de paquets système, ou les binaires officiels). Poetry, contrairement à pipenv, ne s’installe pas « par version de Python » : une seule installation suffit pour gérer des projets ciblant différentes versions.
- Sur Windows avec plusieurs versions de Python installées,
py -3.11 -m pip install poetryetpy -3.10 -m pip install poetrypeuvent signaler que poetry est déjà présent, car les scripts d’entrée pointent vers le même chemin. L’installation via pipx résout ce problème en isolant complètement l’outil. - Sur Linux, pyenv combiné à pipx offre le workflow le plus prévisible : pyenv gère les interpréteurs, pipx gère les outils CLI, pipenv ou poetry gèrent les dépendances projet par projet.
- L’ancien réflexe
pip install -upour mettre à jour un outil global n’a plus de place dans cette chaîne. Chaque couche a son mécanisme de mise à jour propre.
Le passage de pip à pipenv ou poetry n’est pas un simple changement de commande. C’est une réorganisation de la chaîne d’outillage où chaque étage (interpréteur, outil CLI, dépendances projet) obtient son propre périmètre. Accepter cette séparation dès le départ évite la majorité des conflits de dépendances que pip install -u laissait s’accumuler silencieusement.
