jeanas a écrit 136 commentaires

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 ?

Le problème est assez simple, c'est que Conda et pip ne se parlent pas entre eux.

Si tu installes le paquet foo avec pip dans un environnement Conda, et que tu fais ensuite conda upgrade bar, Conda risque d'installer une version de bar incompatible avec la version de foo, et ainsi de casser foo.

L'inverse vaut aussi. Si tu fais pip install foo et que pip se sent obligé de mettre à jour bar pour satisfaire les dépendances de foo, cela risque de casser le paquet baz de Conda qui dépendait de bar.

Pipenv, c'est une longue histoire. Pour la faire courte, Kenneth Reitz, dans une recherche malsaine de popularité, l'a vendu comme un outil miracle et plus officiel qu'il ne l'était vraiment, alors que Pipenv était encore trop limité, en particulier au niveau de la rapidité. Cela a causé un véritable fiasco, qui est l'une des raisons pour lesquelles toute proposition du type « rendons l'outil X officiel » rencontre beaucoup de résistance aujourd'hui.

À un moment, il n'a plus été maintenu pendant un bon moment. Il a trouvé de nouveaux mainteneurs depuis, donc je ne sais pas trop quoi en penser maintenant.

Quant aux recommandations sur packaging.python.org, elles ne sont malheureusement pas à jour. Cf. https://github.com/pypa/packaging.python.org/issues/1468, issue que j'ai justement ouverte hier.

Désolé, je ne comprends pas la pertinence de Guix dans ce contexte. Guix est un gestionnaire de paquets générique, tourné vers aucun langage en particulier. Il ne sait pas lire ou installer les formats de paquets Python, il ne sait pas créer ou gérer des environnements virtuels, installer un paquet en mode éditable, résoudre les dépendances depuis PyPI, ou que sais-je. Je ne vois pas quel problème il peut résoudre dans ce contexte.

(En plus, Guix ne fonctionne que sous Linux.)

Merci pour les remerciements, ça fait plaisir !

J'utilise Hatch sur Pygments, dont je suis mainteneur (sauf qu'il y a du tox aussi, c'est pour ça que je disais que j'hésite à tanner mes co-mainteneurs pour passer à Hatch alors que je les ai déjà tannés pour qu'on sorte de Make). Et aussi sur d'autres projets qui n'ont pourtant pas de déclaration d'environnements Hatch, par exemple sur Sphinx, en me rajoutant mon fichier hatch.toml perso. Et pour tous mes scripts persos aussi.

Petite précision : Rye utilise Hatchling (le build backend de Hatch) par défaut. Mais il peut marcher avec n'importe quel build backend déclaré dans la table [build-system], de même que Hatch et PDM — mais pas Poetry, qui doit toujours être utilisé avec le backend de Poetry.

Pour un projet en C++, je pense que le mieux de très loin à l'heure actuelle est de prendre un build backend spécialisé, comme meson-python pour Meson ou bien scikit-build pour CMake.

Attention, au nom trompeur de PyInstaller, ce truc génère un .exe , pas un installeur. Le paragraphe de la dépêche est un peu ambigu sur le sujet.

Exact, merci pour la rectification.

Une petite blagues des environnement virtuels quand vous faites du code portable, c'est qu'ils ne s'activent pas de la même façon sous Linux et sous Windows. Ce serait trop simple, il était essentiel de changer \bin ou /scripts pour passer de l'un à l'autre.

Pas faux ; cela dit, de toute façon, l'activation doit être différente, vu qu'il faut un source d'un côté et pas de l'autre, comme les shells ne sont pas les mêmes.

(Apparemment, l'auteur d'origine de virtualenv est d'accord sur le fait que c'était une mauvaise décision, mais la casse de compatibilité si c'était changé aujourd'hui serait monumentale.)

Autre blague des projets portables, les "lock file" qui peuvent ne pas être identiques sous Windows et sous Linux (dependance à mariadb par exemple), sauf que c'est absolument pas géré par le format ni par les outils. C'est juste la m***** en fait.

Qu'est-ce que tu entends par « ne peuvent pas être identiques » ? C'est vrai que les paquets peuvent déclarer des dépendances dépendant de l'OS (et heureusement), et c'est vrai que pip-tools ne permet pas de créer un lock file unique pour toutes les plateformes, mais par contre Poetry le fait toujours, et PDM le fait par défaut.

Oui, j'aurais pu le mettre dans la liste, mais la longueur de la dépêche était déjà trop délirante. J'étais très enthousiaste pour Rye au début car c'était le seul capable de gérer les versions de Python (avec des exécutables précompilés, pas comme pyenv), mais depuis que Hatch a cette fonctionnalité, je suis moins chaud, car Hatch est beaucoup plus mature, même s'il manque encore les lock files à Hatch (pas pour longtemps, espérons-le).

Intéressant retour.

Mais l'évolution du langage qui n'est pas rétrocompatible et qui casse donc toute la base de code de la version précédente, ça, c'est mal.

À la décharge de Python, il y a eu pas mal d'efforts pour améliorer la rétrocompatibilité sur les versions récentes, notamment suite au traumatisme de Python 3 (exemple, autre exemple).

Alors il faut les faire tourner dans un venv séparé et donc les faire communiquer via de l'IPC système. Déjà que Python c'est lent, là, c'est carrément dément.

Je n'ai jamais eu ce cas, mais je suis d'accord que si c'est nécessaire, c'est assez dément.

Si au moins python faisait comme tous les autres langages de programmation (c'est à dire de supporter nativement du FFI)

Je ne comprends pas. ctypes n'est pas un support natif de FFI ? Ni la C API de CPython ?

De manière générale, une grande force de Python aujourd'hui (p.ex. dans les sciences) par rapport à d'autres langages est de pouvoir être mélangé assez facilement à du C, Rust voire même C++, et c'est justement ce qui complique énormément le packaging, comme j'essaierai de l'expliquer dans la prochaine dépêche, donc je ne crois pas qu'on puisse l'accuser de manque de support FFI…

Je fini par le leur signaler et l'on me réponds : Veuillez vider tous les caches de votre navigateur… Je n'avais aucune envie de perdre toutes les connexions de toutes mes sessions web, tous les "J'accepte les cookies", dire non à tous les "Acceptez vous les notifications push?"…

Je ne sais pas si Chrome a un équivalent, mais dans Firefox, il est très facile de ne supprimer que les cookies et le local storage d'un seul site donné sans toucher aux autres.

Et en python, ne pas avoir d'opérateur ternaire pour un language qui se veut lisible, quand on parle du non sujet des concours de C illisible, c'est ce que j'appelle un sacré manque. Et un manque total de cohérence pour vous.

Euh…

https://docs.python.org/3.12/reference/expressions.html#conditional-expressions ?

Je ne connaissais pas cette commande. Elle n'est pas installée sur ma machine…

Essaie de l'installer, elle sera probablement dans le paquet pwgen. Sous Debian ou dérivés (comme Ubuntu), ça devrait être sudo apt install pwgen, sous Fedora, sudo dnf install pwgen, …

J'avais vu mais ça ne marche pas :-(

PourMoiÇaMarche® ¯_(ツ)_/¯

_get_random()
{
local char_set
local symbol

symbol="$1"
char_set="$2"

printf "%s\n" "The generated password is :"
strings --bytes=1 < /dev/urandom | tr --delete --complement "{$symbol}" | head --bytes="{LENGHT}" | xargs --null
printf "%s\n" "The password entropy is : (_entropy{char_set}) bits."
}

J'ai écrit un script générant une chaîne de caractères de longueur et complexité variable selon les besoins, histoire de faciliter la génération de login/password pour les services accessibles sur Internet.

Première question : tu ne peux pas utiliser la commande pwgen ?

PS : j'ai du mal avec la mise en page du code, il y a le ${symbol} qui a merdé.

Le code se met dans un bloc encadré par ```. N'hésite pas à utiliser l'aide-mémoire Markdown qui s'affiche en-dessous de la fenêtre de rédaction.

Pourquoi conda serait plus adapté pour le packet wheel ?

Il y a un malentendu : les wheels sont un format qui n'est pas utilisé par Conda, car Conda a son propre format.

Conda est plus adapté pour distribuer du code précompilé, et ça, j'en reparlerai dans la troisième dépêche.

Et pourquoi appeler ça wheel ?

C'est encore une référence aux Monty Python…

https://stackoverflow.com/questions/21113163/wheel-is-a-reference-to-the-other-python

"Wheel" veut dire "roue" mais aussi "meule (de fromage)", et le PyPI est surnommé « cheese shop » d'après le titre d'un sketch des Monty Python, d'où les wheels qu'on récupère au cheese shop.

Note que le problème a déjà été réglé (https://lists.sr.ht/~lioploum/offpunk-devel/%3C4bf5c83950eb5a7f81007b1c6cea15db3e7c0d60.camel%40abou-samra.fr%3E, https://lists.sr.ht/~lioploum/offpunk-devel/%3C169944083399.7.17262020890421882748.208639390%40ploum.eu%3E). Il avait bien compris comment définir les entry points console_scripts, simplement il utilisait Flit, qui ne permet pas d'avoir plusieurs fichiers .py à la racine (il force à avoir soit un seul fichier .py, soit un seul dossier/package avec des fichiers .py dedans).

J'ai posté une suggestion sur la ML du projet.

Euh… Il y a aussi un Python système sous Linux et les gens peuvent se débrouiller pour installer des versions qui ne viennent pas de leur dépôt (et notamment avec Homebrew)

Oui, bien sûr. Simplement, il me semble qu'il est moins fréquent d'installer des Python qui ne viennent pas de la distribution. Mais il y a de la confusion sous Linux aussi.

Sinon, pour les dernières version de MacOS, il n’y a plus de Python et d’autres fournis par Apple…

Je ne suis absolument pas compétent pour macOS, mais de ce que je comprends de l'affaire, le Python qui a été supprimé est un Python 2. Apparemment, il y a encore un Python 3 qui n'est pas préinstallé par défaut mais vient avec les outils en ligne de commande XCode (ensemble qui comprend aussi clang, me semble-t-il). Il y a aussi le Python de Homebrew, le Python de son concurrent MacPorts, et le Python de l'installeur à télécharger sur python.org.

En tous cas, c'est ce que je comprends d'une recherche et notamment de cet article récent : https://www.jcchouinard.com/install-python-on-macos/ . Mais je me trompe peut-être complètement.

Pour ça aussi, il y a le XKCD qui va bien ☺