Discussion :

[Ushuango]

Bonjour

comme beaucoup d'entre vous , je cherche des gestionnaires avec un environnement virtuel pour des bibliothèques python.
J'ai cherché et il ressort que pipenv et poetry sont les deux meilleurs outils pour ça.

Et il semblerait que poetry soit meilleur que pipenv pour la gestion des conflits de dépendances !
Quelqu'un pourrait confirmer cela avec un exemple précis/reproductible pour avoir une preuve.
Car pour l'instant , c'est ce qu'on dit partout, mais je n'ai pas vraiment de preuves.

Merci et bonne fin d'après-midi

[papajoker]

bonjour

et moi, depuis quelque temps, je teste le nouveau venu uv (fait par le développeur de ruff)
https://github.com/astral-sh/uv?tab=...etting-started

A simplified toolchain. uv ships as a single static binary capable of replacing pip, pip-tools, and virtualenv.

a single binary that bootstraps your Python installation and gives you everything you need to be productive with Python, bundling not only pip, pip-tools, and virtualenv, but also pipx, tox, poetry, pyenv, ruff, and more.

------

exemple précis/reproductible pour avoir une preuve.

Bof ! ce sont des applications open sources en perpétuel développement, ce qui est vrai le mois dernier ne l'est plus forcément le mois prochain.
Lire les issues / commits des projets donne une bonne idée

[MPython Alaplancha]

Bonjour.

Pipenv est essentiellement l'équivalent de pip install -r requirements.txt, mais avec la gestion intégrée d'un environnement virtuel.
Poetry possède sa propre gestion des dépendances et de l'environnement virtuel, et il permet également de construire un paquet utilisable par PyPI .

Perso j'ai utilisé poetry pour déposer sur pypi (documentation limpide), sinon si c'est juste pour gérer des dépendances d'un projet perso, j'utilise simplement pip install -r
Je ne connais pas uv mentionné par @papajoker (édit : vu en diagonale: bof )

[wiztricks]

Quelqu'un pourrait confirmer cela avec un exemple précis/reproductible pour avoir une preuve.
Car pour l'instant , c'est ce qu'on dit partout, mais je n'ai pas vraiment de preuves.

Quels besoins motivent l'utilisation d'outils plus sophistiqués que les versions de bases (pip et venv sont livrés avec python en standard)?

Si aujourd'hui vous choisissez la mouture XYZ, qu'est ce qui fera que dans 3/6 mois vous serez tenté d'utiliser l'outil ABC à la place?

Dit autrement, il y a les outils et vos pratiques de développement.
Si les outils peuvent aider à automatiser/fiabiliser des opérations que vous devez réaliser de temps en temps, à défaut de savoir identifier lesquelles, quel sera l'intérêt de les utiliser? Juste à vous rassurer?

De toutes façons, les outils évoluent (et vos besoins aussi...) et si vous réalisez l'application du jour avec ABC, vous pourrez sans doute réaliser celle de demain avec XYZ. Et vous remplacerez (ou pas) ABC par XYZ que si vous devez livrer une nouvelle version de l'application qui l'utilise.

- W

[Ushuango]

Alors pour infos, j'ai trouvé des fonctionnements différents entre pipenv et poetry en ce qui concerne la gestion des dépendances.

faites l'essai:
j'ajoute la librairie pendulum. poetry et pipenvv vont télécharger les librairies qui sont indispensables entre autres , tzdata par exemple.

Puis, je décide que je n'en ai pas besoin, j'en ai choisi une autre.
Donc je la supprime, et là poetry et pipenv ne font pas le même boulot:
- poerty supprime toutes les librairies installées pour pendulum, les dépendances tierces
- pipenv ne supprime que pendulum...

Donc, avec pipenv, on peut se retrouver avec pas mal de librairies qui ne servent à rien pour le projet !

C'est pour ça que je me pose la question de la gestion des conflits de dépendances: quel est l'outil le plus performant entre les deux ?

[umfred]

avec un pipenv clean, après la désinstallation, ça fera le job (ou dans la même commande pipenv uninstall [package] && pipenv clean)

[wiztricks]

Puis, je décide que je n'en ai pas besoin, j'en ai choisi une autre.

A ce niveau on ne code pas, on explore... et tant qu'on n'a pas finalisé ses choix, vaut-il mieux prendre le temps de réfléchir ou de bouger au plus vite dans l'impasse suivante?

C'est pour ça que je me pose la question de la gestion des conflits de dépendances: quel est l'outil le plus performant entre les deux ?

Oui enfin un projet "sérieux", c'est plusieurs semaines de développement. Avant de se lancer à coder, on va choisir les bibliothèques qu'on (sait) utilise(r)a et préférer celles dont on sait qu'elle feront le job (plutôt que d'avoir à la remplacer...)

Et comme finaliser du code prend du temps, au début d'un projet, je m'applique à récupérer les kits d'installations des bibliothèques utilisées (pour pouvoir repartir des mêmes au cas où...) et gérer "à la main" le requirements.txt.

- W

[papajoker]

télécharger les librairies qui sont indispensables entre autres , tzdata par exemple.

Puis, je décide que je n'en ai pas besoin...
on peut se retrouver avec pas mal de librairies qui ne servent à rien pour le projet !
...
la question de la gestion des conflits de dépendances

Ton exemple ne reflète en rien ta question !
Un conflit de dépendance est, pour le même projet qui utilise explicitement "toto" et "tata" : "toto" désire "tzdata" 2.0 mais "tata" désire aussi "tzdata" mais une version 1.x

Ton exemple, c'est juste faire du ménage après installation puis désinstallation. Un conflit de dépendance est à l'installation.
Si tu désires une vue arborescente de tes librairies, tu peux regarder pipdeptree.

Vouloir choisir à l'avance un outil alors que tu ne connais pas réellement ton éventuel futur problème n'a pas de sens. Et privilégier un outil parce qu'il va nous dispenser de penser par nous-mêmes : bof.

[papajoker]

Quels besoins motivent l'utilisation d'outils plus sophistiqués que les versions de bases (pip et venv sont livrés avec python en standard)?

Un article qui fait une syntèse des outils liés aux paquets dans la jungle python et, nous montre clairement par un simple shéma les utilitaires appropriés en fonction de nos besoins.
https://alpopkes.com/posts/python/packaging_tools/

[fred1599]

Bonjour,

Et il semblerait que poetry soit meilleur que pipenv pour la gestion des conflits de dépendances !

Il n'y en a pas de meilleur ! Seulement certains outils font plus de choses de manière automatique, ce qui implique un inconvénient qui est de ne plus savoir ce qu'on fait et laisse le contrôle à ces outils.

Quand on maîtrise un outil, qu'on sait ce qu'on fait, le choix importe peu, c'est une histoire de mise en pratique régulière... J'utilise régulièrement pip et requirements.txt au travail et n'ai jamais eu de problème avec !

J'ai déjà testé poetry qui ne m'a posé aussi aucun problème... Bref, ce qui est important avant d'utiliser ces outils, c'est de savoir ce qu'on veut faire et comment le faire avec l'outil utilisé.

Il n'y a donc pas d'outil préférable pour gérer son environnement de travail.

[Metal3d]

J'ai l'impression que beaucoup de gens ont du mal à comprendre l'intérêt de pipenv (pour ne citer que lui). Je vous lis, et je vois des gens dire que pip et requirements c'est OK. Très bien.
Faites un "pip install torch" et installez d'autres paquets (pandas, numpy, fastapi, etc). Et puis pour l'équipe dev, il faut avoir des lib supplémentaires (pour les tests unitaires par exemple)


Et ensuite générez le requirements avec pip freeze.

Regardez deux secondes le fichier généré.

Faites pareil avec pipenv, et voyez le résultat.

Le second permet tout de même de ne lister que les paquets top level et de séparer le nécessaire pour le dev. Par exemple quand je pose un pipenv pour mon équipe, les paquets de stubs sont dans la section "dev". En prod on ne les deploi pas.

Pipenv permet de mettre le venv dans le projet ou dans un rep de base en dehors. C'est clean, ça marche bien, et c'est beaucoup plus adapté à du dev en équipe et prod.

Il permet de générer un requirements au besoin...

Donc excusez moi mais c'est comme comparer Apt et Dpkg... Vous faites un amalgame. Pip et requirements ce n'est pas exactement pareil.

[fred1599]

Comme je l'ai déjà expliqué, quand on maîtrise son sujet, on fait les choses correctement.


La commande pip freeze est une mauvaise pratique dans la gestion des dépendances, car comme tu l'as mentionné, elle capture le module principal ainsi que toutes ses dépendances, souvent en incluant des versions spécifiques.
Cela peut rapidement rendre le fichier requirements.txt difficile à maintenir, avec des dépendances inutiles ou non souhaitées. Certes, les développeurs expérimentés en sont conscients et évitent cette méthode.


La solution est simple : on doit toujours ajouter manuellement les dépendances dans le fichier requirements.txt en fonction des besoins réels du projet. Cela permet de garder une vue claire et concise des bibliothèques utilisées, ainsi que des raisons de leur inclusion.
Rien n'empêche de rester ouvert aux nouvelles pratiques, mais la clé réside dans la maîtrise de ce que l'on fait et dans une compréhension précise des motivations derrière chaque décision technique.