jeanas a écrit 129 commentaires

J'ai fait cette page pour résumer un certain nombre d'idées reçues sur Unicode (par exemple : on peut comparer des chaînes de caractères de manière insensible à la casse avec string1.lowercase() == string2.lowercase()).

Si vous trouvez une erreur, n'hésitez pas à me la signaler.

J'ai mis à jour la page https://jean.abou-samra.fr/password.html avec des explications et des remarques issues des commentaires (merci à tous !). J'ai aussi mis un avertissement clair de « à vos risques et périls ».

J'ai rajouté également un peu de CSS. (Mais franchement, c'est plus pour me forcer à apprendre un minimum de CSS qu'autre chose. D'ailleurs je suis sûr que je m'y prends comme un pied et qu'il y a des Web-devs dans le coin qui vont voir mes erreurs, ne vous gênez pas, j'aime apprendre. Et je pourrais ranter sur le fait les navigateurs ne rendent pas une page HTML simple sans CSS avec avec un thème suffisamment lisible par défaut pour qu'il n'y ait pas besoin de systématiquement rajouter du CSS, mais c'est pour un autre journal.)

en fait c'est surtout cette question :

Pourquoi un tel système n'est-il pas universel ? Je me le demande bien.

qui m'a faire répondre "mauvaise idée". Dans un cadre individuel, si tu es conscient des limites de ton système, tu fais bien ce que tu veux :p. Je suis pas blanc-blanc non plus, je ne vais pas donner des leçons :D.

Ah, merci pour la clarification. Mais quand je disais ça, je parlais du principe général, pas de l'algorithme exact. Il est évident qu'il ne faudrait pas qu'un outil utilisant un tel système devienne standard dans la population générale sans que des chercheurs en crypto se penchent très sérieusement sur les algorithmes exacts qui sont utilisés.

Par ailleurs, un sel par personne, je ne crois pas que ce soit si pire par rapport à un sel par mot de passe, vu que tu n'as généralement pas deux comptes sur un même site. Ça continue de protéger de la tabulation de mots de passe courants et des collisions entre mots de passe dans une même DB. Mais je ne suis pas assez expert pour juger vraiment.

En fait, je pense que le plus gros problème avec cette histoire, c'est que l'utilisateur moyen va avoir du mal à retenir le message qu'il ne faut jamais mettre son mot de passe maître dans quoi que ce soit dans lequel on n'a pas une confiance absolue. Je crois que voir la différence entre « je me connecte au site foobar en entrant mon mot de passe maître dans un widget de l'OS ou dans un site séparé, et en copiant le résultat sur foobar » et « le site foobar me demande mon mot de passe maître, je le rentre », c'est un peu trop demander à Madame Michu ☹

Je me suis dit qu'on pouvait le voir dans l'autre sens : l'apex est le sel, et le "mot de passe" est réutilisé sur tous les sites. Sauf que dans ce cas, ton sel est très simple à connaître (typiquement ebay, linuxfr, impots…). Reste le mot de passe qui est costaud, mais réutilisé partout.

Oui, je ne pense pas qu'on puisse vraiment parler de sel pour l'apex. C'est plutôt le mot de passe qui doit être suffisamment fort pour être équivalent à un mot de passe normal + un sel décent.

Si tu n'as pas de bol, et que tu tombes un jour sur une machine avec un keylogger ou un logiciel espion quelconque (genre chez le neveu qui rulez sur le darknet), ton mot de passe maître se retrouve compromis et le générateur n'est pas protégé par de la double authentification. Tu as donc tes fameuses 3/4 heures pour rechanger tes mots de passes partout, en compétition avec les amis de ton neveu. 3, 2, 1, partez !

Alors oui. Mais d'un autre côté… Si je tombe sur un keylogger et que je consulte ma boîte mail, j'ai perdu parce que le mail aujourd'hui est la clé d'accès à tout (outre que je n'ai pas envie qu'on lise mes mails perso). Donc je trouve que la sécurité n'est pas si différente du système usuel des mots de passe : après tout, le mot de passe de la boîte mail est une sorte de mot de passe maître. Le but n'était pas d'améliorer la sécurité du système « normal », plutôt d'améliorer l'utilisabilité à sécurité plus ou moins constante. Et je suis d'accord sur le fait qu'à défaut de WebAuthn, la MFA devrait se généraliser le plus possible, pour les sites à données sensibles (bon, honnêtement, seulement sur eux, parce que je n'ai pas spécialement envie d'avoir besoin d'un appareil pour MFA à portée de main dès que je me connecte sur le moindre forum ou blog sur lequel je veux commenter).

J'accepte la critique d'autodidaxie. Cela dit, on reste sur un système qui n'est utilisé que par moi et qui n'engage que moi, pas quelque chose que j'utiliserais dans une Web-application grand public (tiens, je devrais mettre un avertissement sur la page password.html).

C'est vrai que j'aurais pu mettre un sel, c'est un peu bête de ma part. Cela dit, le mot de passe maître est plutôt long (20 caractères aléatoires), ce qui compense un peu. L'intérêt du sel est multiple, mais il permet en particulier d'éviter que les hashs ne soient matchés contre une base de données de mots de passe courants, et en l'occurrence ça ne va pas y être. Un autre intérêt, c'est d'éviter les collisions entre mots de passe qui se trouveraient être égaux, pour répartir le risque, mais tous mes mots de passe sont différents par construction (à cause de l'apex). Et il y a une question d'échelle qui joue aussi : si j'étais Facebook, il serait clairement essentiel d'associer à différents mots de passe des sels différents, parce qu'il y a tellement de mots de passe dans la DB et tellement de valeur à retirer d'un craquage — donc tellement d'enjeu — qu'il y a un risque évident, si on prend le même sel à chaque fois, que des gens investissent des ressources de calcul importantes pour créer une table géante des hashes des mots de passe courants concaténés avec ce sel particulier. Mais là, on parle d'une personne dans le monde avec cent pauvre mots de passe, et qui n'est pas non plus ciblée par la NSA. Je ne crois pas que changer le sel à chaque fois soit essentiel dans ce cas de figure.

Et j'accepte aussi la critique d'avoir utilisé SHA256 et pas une fonction de hachage un peu dure à calculer. Mais l'API window.crypto.subtle.digest des navigateurs n'a que le SHA1 (pas sécurisé), le SHA256, le SHA384 et le SHA512. Je ne voulais pas introduire des dépendances JavaScript, d'abord je n'y connais rien au développement Web, et ça fait de la maintenance (et, paradoxalement, un risque de vulnérabilités si j'oublie de mettre à jour la dépendance…).

Dans le dernier paragraphe tu indique qu'il est possible de modifier rapidement les mots de passe aléatoirement en quelques minutes mais par expérience cela me prends une bonne journée pour modifier les centaines de comptes qui sont stocké dans mon coffre.

Relis le paragraphe en question :) J'ai dit que ça devrait être facile, pas que ça l'est (c'est bien le problème).

Le hic, c'est que si je m'auto-héberge un VaultWarden… je dépends de mon hébergeur. Je n'ai pas envie / pas le temps de m'occuper d'un serveur chez moi accessible sur le réseau extérieur.

Là, j'ai certes une page HTML sur le site qui est servi par mon hébergeur, mais c'est une simple commodité. Tant que la commande cksum existera, le système marchera toujours.

pour un site important, je prendrais certainement un autre mot de passe maître fort (mais bon, je m'attends à ce qu'un site important comme ma mutuelle fasse vraiment attention aux fuites), et si ce n'est pas un site important, je ne me gênerai pas à changer bêtement le « apexdomaine » en « apexdomaine00 » ou quelque chose dans ce genre.

Je ne sais pas pourquoi j'ai écrit ça, il suffit de changer « apexdomaine » en « apexdomaine1 » et regénérer, ou bien j'ai loupé une faille.

Ah, je me disais bien que ça devait forcément exister, merci pour les liens !

S’il y a une fuite de donnée et donc le besoin de changer de mot de passe, il faut soit mémoriser un autre mot de passe maître pour ce site, soit changer tous les mots de passe… Ce qui est une plaie.

C'est vrai. Cela dit, pour un site important, je prendrais certainement un autre mot de passe maître fort (mais bon, je m'attends à ce qu'un site important comme ma mutuelle fasse vraiment attention aux fuites), et si ce n'est pas un site important, je ne me gênerai pas à changer bêtement le « apexdomaine » en « apexdomaine00 » ou quelque chose dans ce genre.

Je verrai si ça fonctionne bien pour moi, on en reparle dans quelques années 🙂

Je ne comprends pas trop la question. Tu parles du code source de la page https://jean.abou-samra.fr/password.html ? Pourquoi ne pas faire « Clic droit > Code source de la page » ou équivalent dans ton navigateur (ou curl -O https://jean.abou-samra.fr/password.html dans un terminal) ? Je sais que c'est inhabituel en 2024, mais il existe encore des sites dans le monde où le HTML est écrit à la main et pas avec un générateur de site statique + npm + 500 dépendances JavaScript + feuilles de style SCSS 🙂

C'est sûr qu'il faut que le mot de passe maître soit fort, puisque tout repose sur lui. En l'occurrence, dans le mot de passe que j'ai choisi, il y a 20 caractères alphanumériques essentiellement aléatoires, donc possibilités. D'après Wikipédia, 2022 a marqué le franchissement de la barre des flops par un superordinateur. Si ce superordinateur cherchait une préimage de mon mot de passe haché à raison d'un essai par flop (vitesse hautement irréaliste, il faudrait plutôt quelques centaines de flops sans doute, mais on n'est pas à 2 ou 3 ordres de grandeur près dans ce genre de calcul), il lui faudrait autour de secondes pour tester toutes les possibilités. Par comparaison, une année fait dans les secondes. Il faudrait donc dans les dizaines de milliards d'années. Je pense qu'on est pas mal.

Ce n'est pas pour rien qu'on utilise le SHA256 (et ses cousins comme le SHA512) en cryptographie. Trouver une préimage est complètement hors de portée à l'heure actuelle. Par exemple, Git est en train de passer au SHA256 pour calculer les identifiants des commits et autres (c'est SHA1 par défaut aujourd'hui, mais SHA1 a des vulnérabilités connues).

Je ne sais pas ce que tu veux dire par "installer un packet en mode éditable".

Je parle de ce que fait l'option -e / --editable de pip install. Elle permet d'installer un paquet dont on a le code source en local, d'une manière qui ne copie pas les fichiers dans le dossier d'installation mais crée une sorte de symlink, afin qu'on puisse éditer le code et voir immédiatement les changements sans réinstaller. (Techniquement, ce ne sont pas des symlinks, mais c'est l'idée.)

Nix ne fonctionne pas non plus sous windows (enfin si, dans le WSL). Si c'est un problème pour toi, alors en effet, sinon cela marche très bien.

Oh, la question n'est pas tellement mon propre usage ; dans cette dépêche, j'ai présenté les outils qui sont répandus dans la communauté Python parce qu'ils sont multiplateforme, Nix n'était donc pas dans le sujet, mais je ne doute pas que c'est un super outil sous Linux.

En tous cas, merci pour les infos sur Nix, que je connais mal et qui a l'air intéressant.

Certes, dans une distrib Linux classique, une poignée de dépendances sont dupliquées avec plusieurs versions, comme dans ton exemple de libssl, mais c'est tout de même plutôt rare. La grande majorité des paquets sont fournis avec une seule version. D'après mon expérience, les mainteneurs de distribution rechignent généralement à avoir plusieurs versions et font le ménage dès qu'une version n'a plus lieu d'être. Ensuite, il est effectivement vrai qu'il existe des distributions moins classiques comme Nix où ce n'est pas le cas, mais je n'ai pas dit que c'était le cas dans absolument toutes les distribs (« on parvient à faire des distributions Linux »).

Avec Python, un mécanisme similaire pourrait être retenu, permettant d’installer autant de versions que l’on veut sans provoquer de conflits, quitte à étendre quelques syntaxes pour aider à désambiguïser.

L'idée revient de temps en temps, mais il y a un large consensus sur le fait que ce n'est pas une bonne idée pour Python. Ça a existé par le passé, dans setuptools, et ça n'a jamais été une réussite.

https://discuss.python.org/t/allowing-multiple-versions-of-same-python-package-in-pythonpath/2219

https://discuss.python.org/t/installing-multiple-versions-of-a-package/4862

Donc, le site de la DGFiP ne supporte pas une configuration recommandée par l'État dans l'administration française.

Tout est normal.

D'après https://blog.bacpluszero.com/2023/05/04/ma-reponse-au-directeur-de-la-strategie-de-meteo-france/ , la vente de ces données représentait 0,5% du budget de Météo France. Ils s'en remettront.

Hypothèse intéressante, donc j'ai cherché à en savoir plus.

D'abord, d'après https://gs.statcounter.com/platform-market-share/desktop-mobile/worldwide/, il n'y a en fait « que » 60% du trafic Internet qui provient de smartphones.

Mais surtout, je suis surpris que

https://gs.statcounter.com/browser-market-share/desktop/worldwide/

et

https://gs.statcounter.com/browser-market-share/mobile/worldwide/

donnent Chrome à des parts de marchés quasi-identiques pour le trafic bureau et le trafic mobile.

En particulier, il y a ≈65% du trafic desktop qui provient de Chrome. Ça fait quand même beaucoup d'utilisateurs de Windows sous Chrome…

Ce n'était pas un lapsus, et je voulais dire que popularité(Chrome) >> popularité(Firefox) s'explique par force_publicitaire(Google) >> force_publicitaire(Mozilla) mais que popularité(Chrome) >> popularité(Edge) ne peut pas s'expliquer de la même manière vu que force_publicitaire(Google) ≈ force_publicitaire(Microsoft).

Je disais ça car je l'utilise sous iOS (oui oui je sais, iOS, je précise qu'il y avait des contraintes particulières sur le choix), et je suis un peu frustré (quand même pas assez pour passer à Safari), notamment par l'expérience de lecture de fichiers PDF (scrolling qui revient au début aléatoirement, recherche qui ne fonctionne pas, copier-coller impossible).

Sur Android, c'est complètement différent et je n'ai aucune expérience. Non seulement ce n'est pas le même code d'interface, mais Firefox pour iOS est forcé d'utiliser WebKit (!), à cause de règles complètement anticoncurrentielles imposées par Apple que les autorités n'ont pas épinglées (!!!).

Par ailleurs, je suis bien d'accord que c'est très pratique d'avoir la synchronisation avec le desktop.

Que Firefox ait une popularité anémique, je veux bien le comprendre, vu qu'il n'est installé à peu près nulle part par défaut sauf sur certaines distributions Linux, et qu'il n'est pas si bon sur mobile. Ce qui m'étonne beaucoup plus, c'est que Chrome a une domination écrasante sur Edge, alors que Edge est quand même installé par défaut sur Windows et bénéficie a priori de la force de frappe publicitaire de Microsoft autrement plus importante que celle de Mozilla. Est-ce que c'est juste une habitude prise par les gens du temps où Edge était merdique ? Est-ce que c'est une question de synchronisation avec les appareils Android ? J'aimerais vraiment comprendre.

Oui, c'est vrai que mamba est normalement meilleur. Après, dans le cas que j'ai cité dans la dépêche (l'environnement avec poppler-qt5 et autres), je l'ai essayé et il gagnait environ 30 secondes sur les 7 minutes. Mais bon, je ne vais pas faire des généralités, je ne l'ai testé que sur une seule résolution.

https://chriswarrick.com/blog/2019/02/15/modern-web-development-where-you-need-500-packages-to-build-bootstrap/

section « Copyrighted one-liners »

Bonjour,

Poetry peut gérer des groupes de dépendances différents, typiquement pour la documentation ou les tests. Ce n'est donc pas vrai que l'on soit forcé d'avoir des dépendances compatible pour le développement du code et le doc etc…

https://python-poetry.org/docs/managing-dependencies/

Désolé de te contredire, mais c'est sur cette même page de la documentation Poetry que j'ai vérifié mes affirmations, et il est bien écrit explicitement : « All dependencies must be compatible with each other across groups since they will be resolved regardless of whether they are required for installation or not (see Installing group dependencies). »

Je viens de faire un test concret et je confirme ce que j'ai écrit dans la dépêche :

~/tmp/poetry-test $ tree
.
└── pyproject.toml

1 directory, 1 file


~/tmp/poetry-test $ cat pyproject.toml 
[build-system]
requires = ["poetry-core"]
build-backend = "poetry.core.masonry.api"

[tool.poetry]
name = "poetry-test"
version = "0"
authors = ["Jean Abou Samra"]
description = "Test"

[tool.poetry.dependencies]
python = ">=3.8"
docutils = "^0.20"

[tool.poetry.group.docs.dependencies]
sphinx = "^6.2"


~/tmp/poetry-test $ poetry lock
Updating dependencies
Resolving dependencies... (0.2s)

Because no versions of sphinx match >6.2,<6.2.1 || >6.2.1,<7.0
 and sphinx (6.2.0) depends on docutils (>=0.18.1,<0.20), sphinx (>=6.2,<6.2.1 || >6.2.1,<7.0) requires docutils (>=0.18.1,<0.20).
And because sphinx (6.2.1) depends on docutils (>=0.18.1,<0.20), sphinx (>=6.2,<7.0) requires docutils (>=0.18.1,<0.20).
So, because poetry-test depends on both docutils (^0.20) and sphinx (^6.2), version solving failed.

Sur la lenteur du solveur il semble que ce soit principalement du au téléchargement parfois nécessaire des paquets insuffisamment bien packagé sur pypi pour résoudre plus précisément le dag

https://python-poetry.org/docs/faq/#why-is-the-dependency-resolution-process-slow

Pour la postérité, il est écrit « While the dependency resolver at the heart of Poetry is highly optimized and should be fast enough for most cases, with certain sets of dependencies it can take time to find a valid solution. This is due to the fact that not all libraries on PyPI have properly declared their metadata and, as such, they are not available via the PyPI JSON API. At this point, Poetry has no choice but to download the packages and inspect them to get the necessary information. This is an expensive operation, both in bandwidth and time, which is why it seems this is a long process. »

En dehors du fait que je ne comprends pas ce qu'ils entendent précisément par « have not properly declared their metadata », j'ai l'impression que ce n'est plus vrai depuis 6 mois, maintenant que PyPI expose les métadonnées des sdists et wheels de manière indépendante de leur téléchargement (PEP 658). pip en tire parti, par contre apparemment Poetry ne va pas le faire. Mais j'ai peut-être mal compris (je regarderai demain un peu plus en détail).

Enfin Poetry a un développement que je trouve stable, solide, tranquille qui respecte ses utilisateurs.

Je crois qu'il y a eu quelques controverses à ce sujet (ici par exemple). Après, c'est très subjectif, mon propos n'est pas de donner une opinion là-dessus. Si tu es content de Poetry, tant mieux.

s/PiPy/PyPI

Avec pip install X Y, pip recherche des versions de X, de Y et de toutes leurs dépendances qui soient compatibles entre elles.

Avec pip install X suivi de pip install Y, la première commande installe seulement X avec ses dépendances, puis la deuxième commande ne prend pas en compte X, résout uniquement les dépendances de Y, et peut casser X en installant des dépendances incompatibles.

C'est ce qui se passe dans l'exemple de la dépêche où pip install myst-parser suivi de pip install mdformat-deflist donne un environnement cassé, alors que pip install myst-parser mdformat-deflist fonctionnerait.

D'accord ok mais du coup cela ne pose-t-il pas un pb d'orchestrer l'ensemble qui fonctionne dans des environnements séparés ? si mon application dépend de lib1 dans env1 (et qui partagerait cet environnement, pour faire plus simple), et de lib2 dans env2, combien ai-je d’interpréteurs lancés ? Faut-il des mécanismes particuliers pour partager les données s'il y en a plusieurs ? Ou alors je suis a côté de la plaque et l'env est complètement transparent pour au runtime.

Ah… mais non, il y a un environnement par application, pas un environnement par dépendance de chaque application. Si j'installe Sphinx avec pipx install sphinx, pipx va créer un environnement pour Sphinx, et mettre toutes les dépendances de Sphinx dans cet environnement, donc aucune interaction entre environnements, Sphinx s'exécute juste à l'intérieur de cet environnement. Par contre, si je fais ensuite pipx install hatch, il y aura un environnement séparé pour Hatch.

Par ailleurs comme tu le soulignes pour les distributions linux, on n'utilise pas directement pip pour installer les paquets mais la distribution qui bénéficient du travail de ces mainteneurs. Cela rendrait l'utilisation de pipx superflue dans ce cas non ?

Oui, si on dispose d'un paquet de sa distribution et qu'on préfère l'utiliser, on n'a pas besoin de pipx. Par contre, s'il n'y a pas de paquet dans la distribution, ou si ce n'est pas la bonne version, il faut passer par pipx. (Et accessoirement, si on est sous macOS ou Windows, on n'a pas le choix.)

Quand à l'espace disque utilisé : il me semble que python laisse un fichier compilé des modules lancés, ce qui multiplie l'espace utilisé.
Je viens de l'embarqué, l'optimisation de l'espace disque reste un critère dans les choix de design. C'est moins le cas pour des applications desktops.

Ces fichiers contiennent du « bytecode », un code intermédiaire qui est de bas niveau mais pas du code natif. Ce n'est pas si lourd.

Dans mon ~/.local/pipx/, ces fichiers font moins d'un quart de la taille totale (88 Mo / 379 Mo, les 88 Mo sont comptés par du --si -ch $(fd -g '*.pyc')).

Alors le lock file est il un fichier pour le "packageur" ou l'utilisateur ?

Ça dépend de quel utilisateur on parle, mais en tous cas, jamais pour un "packageur" lorsqu'il distribue une librairie ou application. Mettons que je développe l'application Sphinx. Il est absolument hors de question que je crée un lock file pour fixer toutes les dépendances de Sphinx et que j'en fasse les dépendances du paquet que je distribue. Par exemple, si je le fais, les mainteneurs de distributions Linux vont me détester parce que je vais forcer les versions exactes de tous les paquets dont je dépends. Par exemple, je vais exiger jinja2 3.1.2. Et il suffirait que le mainteneur d'une autre application, disons Flask , fasse la même chose mais exige jinja2 3.1.1, pour qu'il devienne impossible à la distribution de proposer à la fois Sphinx et Flask.

Par contre, si je suis développeur d'une librairie, mettons foo, et que foo utilise Sphinx comme outil de documentation, je peux avoir un lock file qui fixe les versions de Sphinx et de ses dépendances que je veux pour générer ma documentation. Mais le contenu de ce lock file n'a rien à voir avec les dépendances de ma librairie foo elle-même. Les utilisateurs de ma librairie foo ne verront jamais mon lock file, ils verront juste ma jolie documentation.

Est-ce que la finalité de ces différents backend c'est de pousser les paquets sur pypi ?

Par définition, un build backend est ce qui génère les fichiers sdist et wheel, qui sont les formats distribués sur PyPI. Donc, tous les build backends (dont Hatchling, Poetry-core, PDM-backend et Flit-core) permettent de distribuer sur PyPI, il n'y a aucun problème d'interopérabilité à ce niveau-là.

En fait j'essaie de compiler en tête les critères pour sélectionner un backend plutôt qu'un autre, dans une sorte de table tu vois.

Attention à ne pas confondre le choix du build backend avec le choix d'un outil plus large qui maintient des environnements, compile des lock files et ce genre de choses. En particulier, si tu as besoin de lock files avec Conda, tu peux utiliser PDM, et PDM te laisse le choix du build backend (il possède son propre build backend PDM-backend, mais ce n'est pas une obligation de l'utiliser, tu peux aussi te servir de PDM tout en ayant Hatchling, Poetry-core ou Flit-core comme build backend).

Bêtement je pensais utiliser pyinstaller pour un truc très simple à fournir à un utilisateur non-developpeur. Mais visiblement on propose cet outil pour freezer plus que pour distribuer un package, même si pyinstaller génèrerait les bons fichiers pour.

Disons que le freeze est une première étape. Ensuite, on peut passer un coup de Inno Setup par exemple.

J'ai une connaissance qui a utilisé poetry, visiblement à cause de la complexité des dépendances de l'application utilisé. Je prends peut-être un raccourci, mais genre si la gestion du packaging est est complexe a cause des dépendances alors prends poetry qui t'évitera les accidents.

Le résolveur de Poetry est effectivement censé faire des choix plus malins en contrepartie du temps qu'il prend. Je n'ai pas d'expérience pour savoir si les avantages sont substantiels.

Comme je l'écrivais dans la dépêche, il résout toutes les dépendances en même temps (dépendances du projet mais aussi de ses outils de test et de documentation), ce qui peut causer des problèmes inutilement.

Ensuite j'ai l'impression qu'anaconda vise un milieu bien particulier pour les applications : une simple recherche google et dans le résumé du lien je lis : "Python/R data science and machine learning on a single machine".

Oui, Conda s'adresse clairement à un public de calcul scientifique.

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 ?