L’outil de gestion de projet Python Poetry est sorti en version 1.0.0 ! Sa date de naissance est officiellement le jeudi 12 décembre 2019.
Poetry est un programme en ligne de commande permettant aux développeurs de gérer les métadonnées d’un projet, les dépendances, l’environnement de développement, la génération de livrables, la publication, l’environnement d’exécution et d’autres choses. Le tout de manière unifiée.
À l’origine du projet se trouve le Français Sébastien Eustace. À partir de cette version 1.0.0, le projet Poetry est géré par une équipe nommé sobrement python-poetry avec son propre site et sa propre organisation GitHub.
Sommaire
- Historique de la gestion de projet Python
- Ce qu’apporte Poetry dans l’univers Python
- Poetry propose un ensemble de fonctionnalités complet et clair
- Un projet qui a de l’avenir
Python a beaucoup d’héritage pour la gestion de projet : distutils, eggs, setuptools, easy_install, virtualenv, pip, wheel, pip-tools, twine, pipenv, etc. Cela fait beaucoup d’outils, qui se complètent, se succèdent avec plus ou moins de coopération. Petit rappel des besoins d’un développeur Python :
- définir les métadonnées du projet : nom, version, etc. ;
- définir le contenu du projet : code, ressources, docs ;
- définir les dépendances d’exécution et de développement ;
- figer les versions des dépendances, en respectant les incompatibilités ;
- isoler l’exécution du projet (en dév, en prod) avec un virtualenv et pyenv ;
- générer un livrable (du projet, de l’environnement) : source (
.tar.gz
) et binaire (.whl
) ; - publier ce livrable sur un dépôt public comme PyPI.
Historique de la gestion de projet Python
Voici une petite tentative de récapitulatif simplifié (!) de l’historique de la gestion de dépendances Python.
Au début, on ne génère que des sources avec un fichier setup.py
, retenez‑le bien ! python setup.py install
installe le projet. setup.py
appelle distutils.setup
. Charge aux distributions de faire des paquets binaires, de gérer les dépendances.
L’entreprise TeleCommunity apporte sa contribution : setuptools
. Ce projet inclut : une surcouche extensible à distutils.setup
, la commande easy_install
pour télécharger et installer un projet et ses dépendances, le format egg inspiré du format JAR, un API pkg_resources
pour inspecter l’installation de projets (métadonnées et fichiers ressources). Il reste des problèmes. Par exemple, on ne peut pas désinstaller un projet. Mais avec l’avantage du premier arrivé, l’adoption est massive.
Le prolifique Ian Bicking invente les virtualenvs et pip. Un virtualenv est un duo de dossiers site-packages
et bin
où sont installés des paquets Python. Quand on active le virtualenv, on injecte ces dossiers respectivement en début de PYTHONPATH
et PATH
. Cela évite de polluer ~/.local
, ~/bin
ou pire /usr/local/bin
et /usr/bin
.
pip est un remplaçant d’easy_install permettant — ô miracle — de désinstaller un paquet Python. pip coopère avec les virtualenvs. pip apporte une fonctionnalité intéressante : le fichier requirements.txt
qu’on peut générer avec la commande pip freeze
. Ce fichier contient la liste à plat de tous les projets à installer pour exécuter une application, en figeant la version de chaque projet. Cela facilite la création d’environnement reproductible avec pip
.
pip n’a jamais adopté le format .egg
d’easy_install, et execute systématiquement setup.py install
. C’est long, provoque des erreurs. Certains setup.py
sont compliqués, avec des dépendances pour le setup.py
lui‑même. Mais comment dire à pip que pour exécuter setup.py
, il faut telle version de setuptools voire pbr ou plus ?
Arrive wheel, un format d’archive pure : on ne fait qu’extraire des fichiers de métadonnées ou du projet, sans exécuter quoi que ce soit, pas même un postinst. wheel est un format binaire, on peut générer un livrable wheel pour différents systèmes d’exploitation et architectures matérielles.
Chaque projet se retrouve avec une ribambelle de fichiers qui s’allonge avec le temps : setup.py
, MANIFEST.in
, setup.cfg
, requirements.txt
, requirements-dev.txt
, requirements.in
, .python‑version
, etc. sans compter les tox.ini
, flake8.cfg
et les incontournables README
, AUTHORS
, LICENSE
, etc.
Le très controversé Kenneth Reitz propose Pipenv. Il s’agit d’un outil supplémentaire pour combiner virtualenv, pip et pip‑tools de manière opaque. Avec ce projet, on ajoute deux fichiers Pipfile
et Pipfile.lock
maintenus essentiellement par la commande pipenv
. Kenneth arrive même à faire croire que Pipenv est le remplaçant officiel de pip.
À l’instar de package.json
ou cargo.toml
, la Python Package Authority (PyPA) ajout un nouveau fichier : pyproject.toml
. Le but de ce fichier est de décrire les dépendances d’installation d’un projet. Par défaut, pip
considère que c’est setuptools. De là, plusieurs alternatives sont nées : hatch et Poetry.
Ce qu’apporte Poetry dans l’univers Python
Dernier de la bande, Poetry permet d’étendre pyproject.toml
pour en faire l’équivalent de package.json
, cargo.toml
, etc. Poetry ajoute un fichier poetry.lock
et remplace effectivement les fichiers setup.py
, setup.cfg
, MANIFEST.in
, requirements.txt
et requirements-dev.txt
. On peut éventuellement se passer de tox.ini
également.
Poetry remplace aussi les commandes virtualenv
, twine
, wheel
et pip-tools
.
Le cœur de Poetry est un moteur de résolution de dépendances très pointu qui permet de trouver la meilleure solution pour satisfaire des contraintes parfois très complexes. pip fait un choix pragmatique et ne garantit pas de trouver l’ensemble de versions compatibles. Mieux vaut s’assurer qu’un déploiement est correct grâce à pip check
. Poetry permet de fournir à pip
un requirements.txt
fiable que pip n’aura qu’à appliquer consciencieusement.
Poetry propose un ensemble de fonctionnalités complet et clair
Avant de vous noyer dans la documentation, voici un aperçu de ce que Poetry permet de faire :
-
poetry init
initialise un projet en posant quelques questions sur les métadonnées fondamentales ; -
poetry install
initialise un virtualenv et y installe le projet et ses dépendances ; -
poetry add
etpoetry remove
permettent d’ajouter ou retirer des dépendances d’exécution ou de développement ; -
poetry shell
etpoetry run
exécutent du code dans le virtualenv du projet ; -
poetry env
permet de basculer d’une version de Python à l’autre ; -
poetry version
incrémente la version de votre projet selon la spécification SemVer ; -
poetry build
etpoetry publish
génère et téléverse les livrables d’un projet ; -
poetry export
génère un fichierrequirements.txt
pour alimenterpip
; -
poetry update
met à jour l’ensemble des dépendances en garantissant la compatibilité et en ajoutant les nouvelles sous‑dépendances.
Un projet qui a de l’avenir
La 1.0.0 est une version attendue avec, bien sûr, des compromis sur l’étendue des fonctionnalités. Néanmoins, beaucoup de projets peuvent désormais l’intégrer dans leurs chaînes de production.
L’ambition de Poetry est de répondre de manière unifiée au processus de gestion d’un projet Python depuis l’initialisation jusqu’à l’installation en production. Une étape importante pour son avenir sera l’intégration d’un système de greffons pour étendre Poetry lui‑même.
La popularité de Poetry explose en ce moment. Le projet est passé de 4 000 à 8 000 étoiles sur GitHub. Sur PyPI Stats, Poetry dépasse la barre des 10 000 téléchargements quotidiens hors miroirs. Deux ingrédients peuvent expliquer ce succès : une vision claire et complète du projet portée par Sébastien Eustace et un projet technique et communautaire porté humblement, sans problèmes d’égos.
Poetry est disponible et intégré dans de plus en plus de projets ou services comme CircleCI ou DepHell.
Poetry a certainement encore des erreurs de jeunesse : des cas d’usage non gérés, un manque de finition pour certains comportements, des erreurs ou des lenteurs. Néanmoins, l’efficacité d’un pyproject.toml
et un README
simple pour les collègues valent le détour.
En attendant, ne boudons pas notre plaisir ! C’est le moment d’utiliser Poetry pour gérer des petits projets et se faire la main sur un outil prometteur et déjà très agréable à utiliser !
Aller plus loin
- Page du projet python-poetry.org (485 clics)
- Projet sur GitHub (122 clics)
- Historique de l’empaquetage de projet Python par PyPA (29 clics)
- Annonce officielle de Poetry 1.0.0 (37 clics)
# Commentaire supprimé
Posté par Anonyme . Évalué à 10. Dernière modification le 17 décembre 2019 à 14:47.
Ce commentaire a été supprimé par l’équipe de modération.
# Commentaire supprimé
Posté par Anonyme . Évalué à 8.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: re: Le gestionnaire de projet Poetry 1.0.0 est disponible !
Posté par elf32 . Évalué à 1.
Je ne suis pas familier avec la famille RedHat/CentOS/Fedora mais ce commentaire m’intrigue beaucoup. Y a-t-il un procédé « officiel » pour faire un RPM deployable en prod prenant en compte et isolant des dépendances grâce à un requirements.txt et à un virtualenv ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: re: Le gestionnaire de projet Poetry 1.0.0 est disponible !
Posté par Guillawme (site web personnel, Mastodon) . Évalué à 1.
Qu’est-ce que ça m’apporte si j’utilise déjà conda pour gérer les environnements et les paquets ? Est-ce que je peux utiliser seulement certaines fonctionnalités de poetry ? (par exemple, uniquement pour remplacer setup.py et twine).
[^] # Re: re: Le gestionnaire de projet Poetry 1.0.0 est disponible !
Posté par matteli . Évalué à 1.
J'utilise Poetry pour le dev et je préconise pipx pour l'installation en prod.
# Les poètes et le vocabulaire
Posté par groumf . Évalué à 8.
D’abord merci de vouloir facilité la vie des développeurs python et le travail conséquent pour arriver à produire un projet de cette envergure.
En tant que poète
amateur et peu chouette
j'aurai choisi
cette commande-ci
append au lieu de add
juste parce que ça fait six lettres
d'espace je n'aurai pas a mettre
pour aligner mes salades
[^] # Re: Les poètes et le vocabulaire
Posté par Christophe "CHiPs" PETIT (site web personnel) . Évalué à 1.
+1
j'aime bien que les salades soient alignées !
;-)
# Gestionnaire de dépendances ?
Posté par CamilleM . Évalué à 3.
Excellent projet : merci et félicitations aux auteurs.
Un détail : le titre de l'article parle de "Gestionnaire de projet", ce qui peut être un peu ambigu. Plutôt "Gestionnaire de paquets" ou "Gestionnaire de dépendances" (sur leur site "Python packaging and dependency management made easy" ) ?
[^] # Re: Gestionnaire de dépendances ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
[^] # Re: Gestionnaire de dépendances ?
Posté par El Titi . Évalué à 2.
Dommage parce que pour moi ce projet se rapproche plus d'un gestionnaire de projet que de dépendances. Son périmètre est bien plus large en ce sens qu'il permet de structurer et de gérer le cycle de vie d'un projet. On pourrait faire une analogie avec Maven qui se revendique comme tel:
[^] # Re: Gestionnaire de dépendances ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 6. Dernière modification le 19 décembre 2019 à 16:34.
« Gestionnaire de projet » c'est trop flou, entre la gestion de projet au sens management de projet générique, et gestion d'un ou plusieurs projets basés sur du logiciel.
« Gestionnaire de dépendances » c'est juste une partie des fonctionnalités apparemment
Maven dit « gestionnaire de projet logiciel », ce qui est plus précis. J'ai opté pour « gestionnaire de projet Python » du coup (on se doute que si c'est du Python, c'est du logiciel), et si c'est « gestionnaire de projet Python Poetry » on comprend que c'est n'est pas du management générique de projet nommé « Python Poetry ».
# Vivement le prochain projet, qui remplacera tout le monde ?
Posté par Prae . Évalué à 8. Dernière modification le 18 décembre 2019 à 20:56.
Je vais être moins enchanté que pas mal de gens ici.
Ce n'est pas une critique envers Poetry (que je n'ai pas encore utilisé), mais une critique envers l'écosystème Python.
Comme annoncé en début d'article, on a (eu) plusieurs systèmes, chacun avec ses propres mécanismes, ses propres fichiers de confs.
A la fin, si on essaye d'être assez "propre" dans son projet python, on se retrouve avec une tonne de fichiers à la racine, c'est ingérable.
Surtout que cela n'a aucun sens: setup.py n'indique rien de précis (setup.py pourrait-être un fichier de setup du projet en lui-même et non le fichier de 'conf' pour un tool python), cela pourrait être tout et n'importe quoi, idem avec requirements.txt.
Il faudra un jour (peut-être?) avoir un consensus, sinon on va se retrouver avec encore plusieurs outils concurrents et encore plus de fichiers de configurations ou autres bordels.
Déjà, il aurait peut-être été pertinent de mettre tout ce bordel dans un répertoire (.python ?), d'avoir un seul système de packaging (easy_install, pip, pipenv, quoi d'autres la prochaine fois ? python-composer ? apt-python ? npythonm ?).
Ainsi qu'avoir des fichiers de configurations un peu compatibles entre eux (j'évoque ceux qui ont des syntaxes équivalentes mais chacun à son nom de fichier personnalisé sans prendre en compte l'existant, par exemple, alors que son but officieux est de remplacer l'ancien)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 9.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Vivement le prochain projet, qui remplacera tout le monde ?
Posté par Guillawme (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 19 décembre 2019 à 16:14.
Je pense qu’un consensus ou des conventions ne suffisent pas, car ça n’empêche pas de les ignorer. Il y a de très bonnes idées dans R dont Python pourrait/devrait s’inspirer, et le système de paquets en fait partie. Il est très bien décrit (en anglais) dans les chapitres 6 à 15 de ce livre disponible intégralement en ligne : https://r-pkgs.org/
La différence principale comparé aux conventions de Python, c’est que la génération d’un paquet échoue si les conventions ne sont pas suivies : en particulier, mais pas uniquement, les conventions sur l’arborescence et où placer chaque type de fichier (code, documentation formelle, documentation longue, tests, etc.) et les conventions sur les méta-données à renseigner. Forcer une structure homogène aide énormément à explorer le code de quelqu’un d’autre, et aide aussi les outils de développement puisqu’ils n’ont pas à gérer une infinité de configurations.
# Retour vers le futur ?
Posté par Steap . Évalué à 6. Dernière modification le 19 décembre 2019 à 02:49.
Il y a quelques années, on avait au moins 4 façons d'empaqueter notre
projet pour PyPI : setuptools, distutils, distribute et distribute2. Au
bout d'un certain temps, setuptools s'est imposé comme la solution de
facto. Tout le monde (ou presque) déteste setuptools, mais au moins, on
avait une façon standardisée de faire les choses.
Depuis les PEP 517/518 et l'introduction de pyproject.toml, on voit
fleurir divers projets ayant pour objectif de remplacer setuptools,
notamment poetry, flit et hatch. Est-ce qu'on ne va pas se retrouver
dans la situation décrite dans le premier paragraphe ?
Pour en rajouter une couche sur la multiplicité des outils, j'avoue que
j'ai plus ou moins capitulé devant tant de complexité, alors que je suis
développeur Python et que c'est aussi une partie très importante de mon
emploi. Je retrouve en permanence des fichiers .egg-info dans mes
sources alors que le format egg a été déprécié depuis bien longtemps, ce
qui m'étonne. Et j'avoue être incapable de vraiment comprendre à quoi
servent pipx, pipenv, requirements-*.txt, Pipfile, Pipfile.lock, etc.
J'utilise "tox" pour mes tests unitaires, et je me fais parfois des venv
à la main avec "python3 -m venv". Je connais des gens extrêmement bons
en Python qui me disent "bon bah moi, quand je commence un projet, je
copie/colle un vieux setup.py et je modifie ce qu'il faut". Est-ce qu'on
rate vraiment quelque chose ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
# petite question
Posté par Albert_ . Évalué à 4.
Est-ce que cela s'interface bien avec cookiecutter ou est-ce que cela fait doublon? D'après la description il me semble que certaines caractéristiques font doublon mais je peux me tromper :).
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 6.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: petite question
Posté par Albert_ . Évalué à 4.
Totalement merci. J'ai pas mal utilisé cookicutter pour aider les nouveaux devs a avoir une structure propre de programme. Après c'est sur que si tu travailles sur un projet majoritairement et que tu n'y touches plus cela ne sert pas à grand chose :).
# installation
Posté par Goffi (site web personnel, Mastodon) . Évalué à 5.
Ce qui me bloque pour utiliser Poetry à l'heure actuelle, c'est l'installation. On demande d’exécuter aveuglément un script sur un dépôt git qui peut changer à n'importe quel moment. Autant je peux moi même vérifier ce script, autant je me vois mal demander ça à mes utilisateurs. C'est dommage parce qu'en dehors de ça ça a l'air super. Pour
pip
qui est maintenant officiellement distribué avec Python il y aensurepip
, est-ce qu'on a la perspective de quelque chose de similaire à court ou moyen terme ?Pour celles ou ceux qui utilisent déjà Poetry, est-ce que cette installation ne vous pose pas problème ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.