Pipenv : Pourquoi faire ?

Python
3

TL;DR: Je pense que pipenv a commencé comme une implèm de démo de la spec Pipfile (qui prédate pipenv).

Personnellement j’évite les outils “qui-font-tout-c-magique-tkt”, je préfère les outils “qui ne font qu’une chose mais qui le font bien”, ma stack actuelle se compose donc de :

  • setuptools pour packager (setup.cfg et un pyproject.toml, j’espère dans le futur pouvoir me passer de setup.cfg et d’écrire directement dans pyproject.toml.)
  • Des venvs, un par projet, j’ai même un alias bash de 6 lignes pour ça
  • pip

Et non, rien pour épingler mes dépendances, je pense qu’épingler les dépendances (et leurs sous dépendances) est un mensonge, pour plusieurs raisons :

  • Il n’existe pas forcément un ensemble de dépendances compatibles avec les versions de Python avec lesquelles votre projet est compatible.
  • Ça rend le projet incompatible avec les autres (si j’épingle numpy==1.22.1 et que quelqu’un épingle numpy==1.22.0 on ne peut pas installer nos deux projets ensembles).
  • Épingler implique souvent de prendre du retard sur les mises à jour (niveau sécurité c’est une mauvaise idée, on apprend aux gens à mettre à jour régulièrement, c’est pas pour leur fournir de vieilles dépendances).
  • Avoir la CI qui passe parce qu’on utilise un vieux pylint c’est joli, c’est green, mais mettre à jour pylint et se rendre compte que la nouvelle version trouve d’autres vrais bugs, c’est mieux.
  • Avoir la CI qui foire du jour au lendemain à cause d’un bug trouvé par une nouvelle version de pylint ou de mypy ou autre c’est inconfortable mais préférable à l’alternative (laisser un utilisateur final trouver le bug).

Je pense qu’il est préférable de tester différentes versions de nos dépendances dans la CI, pour s’assurer, un peu, qu’on ne ment pas dans le install_requires (qui devrait préciser la version minimale des dépendances, et éventuellement maximale (la prochaine release majeure d’une dépendance utilisant semver est probablement à exclure d’office, je préfère la tester moi-même avant de “relâcher” la contrainte dans install_requires, plutôt que laisser tester ça aux utilisateurs, c’est ce que j’expérimente dans oeis.

Mais pour les cas où on voudrait vraiment épingler, il existe un outil qui ne fait que ça mais qui le fait bien, pip-compile.

Et pour la prod je comprends qu’on puisse vouloir épingler dépendances et sous-dépendances, mais ce n’est pas le boulot du dev, c’est le boulot de celui qui s’occupe de la mise en prod, à lui de versionner un requirements.txt pour le projet qu’il utilise, où il veut (avec ses playbooks Ansible ou autre), et comme il veut. Il n’est même pas obligé de suivre le rythme de release du projet qu’il met en prod, et bonus il peut épingler pour la version de Python qu’il a en prod.

4 « J'aime »