Étude des backends de build utilisés dans les pyproject.toml

Moi qui suis hésitant à tester d’autres backends que setuptools, je suis content de voir qu’il est toujours premier.

Bon pour combien de temps je l’ignore… en tout cas c’est très cool d’avoir ce genre de graph !

Ou sans ceux qui ont moins de 5 utilisations (qui peuvent être des petits wrappers persos typiquement) :

Source (et retoots bienvenus) :

Je suis un peu déçu que flit ne fasse pas plus, il colle bien à la philosophie « ne faire qu’une seule chose mais le faire bien », et pendant qu’on y est il colle bien à « keep it simple » aussi (en essayant pas de gérer les venvs, les dépendances, la vie, et le reste en même temps). S’il y en a un que j’essayerai plus volontiers que les autres (et que j’ai déjà essayé j’avoue) c’est bien celui-là.

Il me semblait que hatchling / hatch étais “mis en avant” par la PIPA.

Après vérification c’est le cas :
https://packaging.python.org/en/latest/tutorials/packaging-projects/

Je n’ai pas encore de vision sur qui fait quoi et pour qui sur le sujet :). J’avais l’impression que hatch étais un peu plus porté par la PiPa et que Flit avait été un précurseur… mais qui avais un peu perdu le vent et se proposait d’être une alternative ultra light pour les cas simples. (intuition basé sur le nombre d’étoiles, de pr et de commit sur Python Packaging Authority · GitHub et de ce que je crois comprendre de la doc de flit)