Le gestionnaire de projet Python Poetry 1.0.0 est disponible !

Posté par  . Édité par Benoît Sibaud, Davy Defaud, Xavier Teyssier et palm123. Modéré par Benoît Sibaud. Licence CC By‑SA.
Étiquettes :
41
17
déc.
2019
Python

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

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 et poetry remove permettent d’ajouter ou retirer des dépendances d’exécution ou de développement ;
  • poetry shell et poetry 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 et poetry publish génère et téléverse les livrables d’un projet ;
  • poetry export génère un fichier requirements.txt pour alimenter pip ;
  • 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

  • # Commentaire supprimé

    Posté par  . É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  . É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  . Évalué à 1.

      Donc pip installe les paquets décrits dans requirements.txt et rpm intègre avec l'écosystème final (notamment la version de python).

      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  . É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  (site web personnel, Mastodon) . Évalué à 1.

      Avez-vous des exemples de cas d'usage, relatif à la gestion de paquet Python et qui pourtant ne seraient pas dans le périmètre fonctionnel de Poetry ? Autrement dit, une fois passé à Poetry, quels sont les autres outils qu'il vous reste à utiliser

      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  . É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  . É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

    poetry add numpy
    poetry append numpy
    poetry remove numpy

  • # Gestionnaire de dépendances ?

    Posté par  . É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  (site web personnel) . Évalué à 3.

      Corrigé, merci.

      • [^] # Re: Gestionnaire de dépendances ?

        Posté par  . É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:

        Apache Maven is a software project management and comprehension tool.

        • [^] # Re: Gestionnaire de dépendances ?

          Posté par  (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  . É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  . É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  (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 19 décembre 2019 à 16:14.

      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.

      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  . É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  . Évalué à 5.

      Ce commentaire a été supprimé par l’équipe de modération.

  • # petite question

    Posté par  . É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  . Évalué à 6.

      Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: petite question

        Posté par  . É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  (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 a ensurepip, 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  . É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.