Re: Excellent article

pipx : un venv par module ?! Doit-on en arriver là ? On parvient bien à faire une distri linux sans dupliquer les dépendances de chaque lib ou outil.

Oui, un venv par outil en ligne de commande installé. Et oui, on parvient à faire des distributions Linux qui ne dupliquent pas les dépendances, mais grâce à des mainteneurs dévoués qui s'occupent de trouver des versions compatibles entre elles pour toute la distribution. PyPI a un modèle social complètement différent, n'importe qui peut y publier, donc ce n'est tout simplement pas possible. Ce modèle a ses inconvénients, comme la duplication entre environnements, ou encore le risque de malware, mais le modèle des distributions a aussi ses inconvénients, comme le fait qu'un paquet relativement peu populaire ou de niche va avoir du mal à faire son chemin dans toutes les distributions, qu'on ne peut pas mettre à jour ou rétrograder arbitrairement un paquet sans changer le système entier, et qu'on ne peut pas tester avec plusieurs versions d'une dépendance à chaque fois.

En pratique, la taille des venvs séparés n'est pas si problématique, surtout que les bibliothèques Python sont pour la plupart écrites en Python, donc pas compilées, ce qui fait que la taille du code (je veux dire le poids des fichiers .py) est relativement petite. Par exemple, sur mon ordinateur, j'ai 15 outils différents installés avec pipx, et le tout fait 379 Mo (du --si ~/.local/pipx/), soit ≈ 25 Mo par application. Ce n'est certes pas optimal, mais pas indécent non plus (je crois que pour les Flatpak, la taille typique est un ordre de grandeur au-dessus...).

Le lock file pas vraiment compris, je vais devoir relire... ah ok c'est un fichier requirements.txt

Pas forcément : requirements.txt est un format possible (mais limité) pour les lock files. Poetry et PDM produisent des lock files dans des formats différents qu'ils comprennent chacun.

Et finalement ces outils vont quand même créer un package installable avec pip ou conda ? ou conda est-il exclusif à son écosystème ?

Je ne suis pas sûr de comprendre la question.

Déjà, il faut voir que c'est un peu une simplification de ma part de dire que l'écosystème Conda est complètement séparé de l'écosystème PyPA, parce que beaucoup de paquets Conda sont créés à partir de paquets PyPI (étant donné que PyPI est l'index historique et de loin le plus utilisé), donc en fait, ces paquets Conda sont générés en appelant pip à l'intérieur du build script Conda. Conséquence : si on a un paquet écrit en Python pur (pas en C/C++/Rust) dans les formats PyPA (sdist et wheel), on peut le convertir en paquet Conda. L'inverse n'est pas vrai : si on a un paquet Conda, on ne peut pas facilement à ma connaissance le convertir en paquet pour PyPI (ce truc a l'air d'être mort).

Ensuite, les lock files servent surtout aux applications en bout de chaîne, par exemple une application Web déployée sur des serveurs, un script de data science, ... Ces projets ne sont généralement pas redistribués comme paquets (Conda ou PyPI). Certes, les lock files peuvent aussi servir sur des librairies, ou des applications redistribuées largement (comme ces outils de packaging eux-mêmes, ou des outils comme Sphinx pour la documentation), mais alors c'est principalement pour fixer les dépendances utilisées pour tester l'application, et normalement jamais pour la liste des dépendances de l'application redistribuée.

Donc, en fait, il n'y a pas vraiment de lien entre lock files et redistribution. Le lien entre les lock files et la question « Conda vs. PyPI », c'est plutôt la question de la source des paquets que demande le lock file. Avec Poetry, il n'est pas possible (à ma connaissance) de générer des lock files qui prennent les paquets sur Conda. Par contre, c'est possible avec PDM.

Est-ce que l'on ne pourrait pas redistribuer les solutions selon la complexité de l'application à packager, ou se trouve-t-on trop rapidement embarquée dans les successions de dépendances ?

Désolé, je ne comprends pas la question, pourrais-tu reformuler ?