Jeune développeur, allons voir si ton wheel,
De son packaging si difficile,
Et de sa robe de pourpre sur ton poste,
A point perdu quand tu exportes
De sa compatibilité si complexe
Et de son gain si perplexe.
Il est en effet assez facile de s’y perdre lors de la gestion des compatibilités entre les différentes versions des packages Python mais aussi et surtout avec les multiples versions de Python à disposition. Nous allons voir à l’aide ce billet de blog une solution nommée Poetry qui promet de nous faciliter la tâche et de rendre le packaging, le build ainsi que le déploiement de nos applications Python aussi simple que possible.
Projet open source, Poetry se base essentiellement sur des outils assez classiques dans le développement des projets Python tel que pip, venv ou pyenv mais apporte une surcouche qui change l’expérience développeur. Un projet géré par Poetry se base essentiellement sur deux fichiers: pyproject.toml et poetry.lock
Regardons ce que contiennent ces deux fichiers.
À l’initialisation de votre projet il est composé de :
Cette distinction entre l’environnement de dev et celui de production nous permet en tant que développeur d’avoir des versions différentes de nos packages ou de nouvelles dépendances qu’il est inutile d’avoir en environnement de production, il est ainsi possible de tester de nouvelles fonctionnalités de manière sereine et isolée sans avoir à installer et ensuite désinstaller ces packages.
Il aura ainsi cette configuration à la création d’un projet nommé, par exemple, poetry-demo:
Le fichier pyproject.toml peut incorporer à lui seul le contenu des fichiers requirements.txt, setup.py, setup.cfg, MANIFEST.in ainsi que le fichier Pipfile. L’ensemble des fonctionnalités qu’il est possible d’intégrer sont listées ici.
Notez aussi l’utilisation de wildcard python = "*" ou encore pytest = "^7.1" pour spécifier les versions de vos dépendances, cette manière de faire offre la possibilité de maitriser les futurs versions que Poetry va installer dans le cas d’un update. Elles ne sont pas forcément figées à une version particulière. Nous y reviendrons un peu plus tard dans l’article.
Une fois vos dépendances installées, Poetry génère un fichier poetry.lock qui centralise toutes les versions exactes de votre projet Python. Ce fichier est capital pour figer les versions des dépendances utilisées. En effet, étant donné que dans le fichier pyproject.toml les versions citées ne sont pas précises avec l’utilisation des wildcards et qu’ils sont souvent amenées à évoluer dans le cas d’une mise à jour, le fichier poetry.lock les renseigne et nous garantit que si ces versions exactes sont installées, alors le projet peut être buildé.
C’est une bonne pratique de rajouter le fichier poetry.lock à git pour garantir aux développeurs (y compris vous même), à votre CI ou encore vos serveurs de production la résilience de votre projet en cas d’une nouvelle release de vos dépendances.
Le fichier pyproject.toml représente la vision à long terme des dépendances en cas d’update, ce qui nous permet d’être serein si un update à lieu. Le fichier poetry.lock quand à lui ****fige ****les versions avec lequelles le programme marche en ce temps T (ce qui assure que le code n’aura pas de conflit de dépendances sur aucune des machines (local, sur la CI, en production, …)).
La surcouche apportée dans Poetry nous apporte une facilité déconcertante dans le développement des projets Python, ainsi il suffit de lancer les commandes suivantes pour:
Cette requête est très utile pour avoir une idée claire des versions utilisées, elle a pour résultat une sorte d’arbre qui contient les dépendances, leurs versions mais aussi les sous dépendances installées, voici son retour pour le projet de démo:
Poetry récupère l’ensemble des versions à installer à partir du fichier poetry.lock s’il est existant. Et s’il n’existe pas (au début du projet par exemple), Poetry se base sur le fichier pyproject.toml pour récupérer les dernières versions disponibles des packages cités.
Cette commande génère un fichier .wheel et un fichier .sdist qui représentent votre projet sous forme de package livrable et réutilisable.
Cette commande permet de déployer votre projet dans un repository privé qui a été préalablement configuré. Si l’option -r n’est pas spécifiée, le déploiement se fera dans pypi.
Comme cité plus haut, il est possible de configurer précisément les nouvelles versions de nos dépendances que Poetry est amené à installer lors d’une commande d’update. Géré par des wildcards, cette manière de faire nous permet d’assurer une actualisation de nos dépendances en évitant, si on le souhaite, de passer à des versions majeures pour éviter de casser la compatibilité.
Par exemple, pour spécifier qu’une dépendance ne peut être actualisée en version majeure on peut utiliser la syntaxe suivante dans votre fichier pyproject.toml:
Cette spécification permettra de mettre à jour le package pytest jusqu’à la version 1.3.0. Ainsi, si une version majeure 2.0.0 est amenée à exister, elle ne sera pas installée pour éviter d’avoir des erreurs de rétro-compatibilité. Pour voir l’ensemble des possibilités que propose Poetry concernant les wlidcards, tout est listé ici.
Poetry regroupe à lui seul un ensemble d’outils que l’on devait auparavant utiliser individuellement pour faire vivre nos projets Python (pyenv, venv, pip, twine, ...). Et il fait bien plus que cela, en s’assurant d’avoir toujours un projet qui a des dépendances à jour sans forcément casser la compatibilité.
Il est en effet assez facile de s’y perdre lors de la gestion des compatibilités entre les différentes versions des packages Python mais aussi et surtout avec les multiples versions de Python à disposition. Nous allons voir à l’aide ce billet de blog une solution nommée Poetry qui promet de nous faciliter la tâche et de rendre le packaging, le build ainsi que le déploiement de nos applications Python aussi simple que possible.
Projet open source, Poetry se base essentiellement sur des outils assez classiques dans le développement des projets Python tel que pip, venv ou pyenv mais apporte une surcouche qui change l’expérience développeur. Un projet géré par Poetry se base essentiellement sur deux fichiers: pyproject.toml et poetry.lock
Regardons ce que contiennent ces deux fichiers.
À l’initialisation de votre projet il est composé de :
Cette distinction entre l’environnement de dev et celui de production nous permet en tant que développeur d’avoir des versions différentes de nos packages ou de nouvelles dépendances qu’il est inutile d’avoir en environnement de production, il est ainsi possible de tester de nouvelles fonctionnalités de manière sereine et isolée sans avoir à installer et ensuite désinstaller ces packages.
Il aura ainsi cette configuration à la création d’un projet nommé, par exemple, poetry-demo:
Le fichier pyproject.toml peut incorporer à lui seul le contenu des fichiers requirements.txt, setup.py, setup.cfg, MANIFEST.in ainsi que le fichier Pipfile. L’ensemble des fonctionnalités qu’il est possible d’intégrer sont listées ici.
Notez aussi l’utilisation de wildcard python = "*" ou encore pytest = "^7.1" pour spécifier les versions de vos dépendances, cette manière de faire offre la possibilité de maitriser les futurs versions que Poetry va installer dans le cas d’un update. Elles ne sont pas forcément figées à une version particulière. Nous y reviendrons un peu plus tard dans l’article.
Une fois vos dépendances installées, Poetry génère un fichier poetry.lock qui centralise toutes les versions exactes de votre projet Python. Ce fichier est capital pour figer les versions des dépendances utilisées. En effet, étant donné que dans le fichier pyproject.toml les versions citées ne sont pas précises avec l’utilisation des wildcards et qu’ils sont souvent amenées à évoluer dans le cas d’une mise à jour, le fichier poetry.lock les renseigne et nous garantit que si ces versions exactes sont installées, alors le projet peut être buildé.
C’est une bonne pratique de rajouter le fichier poetry.lock à git pour garantir aux développeurs (y compris vous même), à votre CI ou encore vos serveurs de production la résilience de votre projet en cas d’une nouvelle release de vos dépendances.
Le fichier pyproject.toml représente la vision à long terme des dépendances en cas d’update, ce qui nous permet d’être serein si un update à lieu. Le fichier poetry.lock quand à lui ****fige ****les versions avec lequelles le programme marche en ce temps T (ce qui assure que le code n’aura pas de conflit de dépendances sur aucune des machines (local, sur la CI, en production, …)).
La surcouche apportée dans Poetry nous apporte une facilité déconcertante dans le développement des projets Python, ainsi il suffit de lancer les commandes suivantes pour:
Cette requête est très utile pour avoir une idée claire des versions utilisées, elle a pour résultat une sorte d’arbre qui contient les dépendances, leurs versions mais aussi les sous dépendances installées, voici son retour pour le projet de démo:
Poetry récupère l’ensemble des versions à installer à partir du fichier poetry.lock s’il est existant. Et s’il n’existe pas (au début du projet par exemple), Poetry se base sur le fichier pyproject.toml pour récupérer les dernières versions disponibles des packages cités.
Cette commande génère un fichier .wheel et un fichier .sdist qui représentent votre projet sous forme de package livrable et réutilisable.
Cette commande permet de déployer votre projet dans un repository privé qui a été préalablement configuré. Si l’option -r n’est pas spécifiée, le déploiement se fera dans pypi.
Comme cité plus haut, il est possible de configurer précisément les nouvelles versions de nos dépendances que Poetry est amené à installer lors d’une commande d’update. Géré par des wildcards, cette manière de faire nous permet d’assurer une actualisation de nos dépendances en évitant, si on le souhaite, de passer à des versions majeures pour éviter de casser la compatibilité.
Par exemple, pour spécifier qu’une dépendance ne peut être actualisée en version majeure on peut utiliser la syntaxe suivante dans votre fichier pyproject.toml:
Cette spécification permettra de mettre à jour le package pytest jusqu’à la version 1.3.0. Ainsi, si une version majeure 2.0.0 est amenée à exister, elle ne sera pas installée pour éviter d’avoir des erreurs de rétro-compatibilité. Pour voir l’ensemble des possibilités que propose Poetry concernant les wlidcards, tout est listé ici.
Poetry regroupe à lui seul un ensemble d’outils que l’on devait auparavant utiliser individuellement pour faire vivre nos projets Python (pyenv, venv, pip, twine, ...). Et il fait bien plus que cela, en s’assurant d’avoir toujours un projet qui a des dépendances à jour sans forcément casser la compatibilité.