Explications et astuces d’utilisation de python poetry

Pour ceux qui sont habitués à utiliser un environnement virtuel «de base» avec virtualenv, poetry peut être déroutant. Voici quelques éclaircissements et certains trucs avec l’utilisation de poetry.

Regardez votre configuration

Exécutez poetry config --list. Ça vous donnera une idée de comment il est configuré.

Poetry «cache» l’environnement virtuel

Mais il existe quand même. Quand vous exécutez poetry install, cet environnement est créé dans un endroit qui dépend de votre configuration. Si virtualenvs.in-project est à false, ce sera dans le répertoire défini par cache-dir. S’il est à true, il sera crée sous le répertoire .venv à partir du répertoire où la commande est exécutée.

Astuce: Définissez virtualenvs.in-project à true

Personnellement, je préfère garder mon environnement virtuel sous la main. Si j’ai besoin de l’effacer pour une quelconque raison (surtout pour des problèmes de cache!), il est directement dans mon projet, je n’ai pas à le chercher.

poetry config virtualenvs.in-project true

Par ailleurs, si je supprime le projet, l’environnement est supprimé en même temps. S’il est dans le répertoire commun, je suppose qu’il y reste indéfiniment.

Que font les commandes run et shell

• run charge l’environnement virtuel et exécute la commande qui suit.
• shell charge l’environnement virtuel et démarre un shell.

Voici l’équivalence non-poetry de ces commandes.

Astuce: Comment travailler avec une dépendance locale en mode modifiable

Si une de vos dépendances est locale (donc pas sur pypi) et qu’il s’agit de code source (donc pas un .zip ou un .whl, une fois qu’elle est installée, vous devez spécifier manuellement dans pyproject.toml de la traiter en mode modifiable. Par exemple:

my-package = {path = "../my/path", develop = true}

Ensuite, vous devez supprimer votre environnement virtuel et le réinstaller. Du moins, c’est le cas au moment d’écrire ces lignes sous poetry 1.1.13. Si une fois le changement fait vous exécutez poetry install ou encore poetry update, le changement n’est pas pris en compte. Si vous inspectez manuellement votre répertoire .venv/lib/python<v>/site-packages/<votre paquet> vous verrez que le code y est toujours copié plutôt que lié.

Donc effacez .venv et exécutez plutôt poetry update.

update. Pas install!

En voici la raison: poetry install va simplement reprendre ce qui est dans poetry.lock et l’installer sans tenir compte du changement de pyproject.toml. Exécuter poetry update le force à mettre à jour poetry.lock, en considérant pyproject.toml avant de procéder correctement à l’installation.

Une fois fait, vous pouvez regarder le répertoire .venv/lib/python<v>/site-packages/et vous devriez y voir <votre paquet>.<extension> où extension peut varier en fonction de ce qui est utilisé pour construire votre paquet .

Astuce: Comment travailler avec une dépendance locale en mode non modifiable

Il est beaucoup plus facile de travailler avec une dépendance en mode modifiable qu’en mode non modifiable. Si pour une raison ou une autre vous êtes coincé et êtes forcé de l’installer en mode non modifiable, il y a une astuce principale à connaître.

Chaque fois que la dépendance change, le numéro de version doit changer.

Sinon, poetry risque de ne pas détecter le changement et de réutiliser le dernier «build» qui a été généré. C’est facilement vérifiable: vous pouvez compare le code copié dans .venv vs la source du paquet. Ils auront divergé.

Astuce: Comment s’assurer que poetry est utilisé pour bâtir une dépendance locale

Même si votre dépendance a un fichier pyproject.toml, même si vous exécutez poetry install pour l’installer, rien ne garanti que poetry sera utilisé pour la bâtir. Vous devez spécifier ceci dans son fichier pyproject.toml:

[build-system]
requires = ["poetry-core>=1.0.0"]
build-backend = "poetry.core.masonry.api"

Je ne suis pas remonté à la cause exacte du problème, mais j’ai pu constater que sans ces directives, plutôt que de créer le «build» dans le répertoire <votre paquet>/build, il est généré sous <votre paquet>/<votre paquet>.egg-info, lequel est un format déprécié selon la documentation de setuptools.

Astuce: N’installez pas les dépendances de développement en production

Lorsque vous installez du code prêt pour la production, par exemple dans une image docker, vous devriez utiliser l’option --no-dev lors de l’installation. (poetry install --no-dev) Ceci fera en sorte que seules les dépendances régulières seront installées, ce qui sera plus rapide, moins volumineux et réduira la surface d’attaque.

Soyez vigilants: Si vous avez des dépendances mal catégorisées qui sont dans le groupe [tool.poetry.dev-dependencies] et qui devraient être dans le groupe [tool.poetry.dependencies], vous obtiendrez un assemblage brisé.