La personne sait que pyproject.toml existe, mais n’a pas voulu l’utiliser, parce que, selon lui, si ça marche faut pas corriger.
Ensuite il explique comment il a galéré comme pas possible. J’ai envie de dire que le prédicat de départ était probablement faux et qu’il aurait dû utiliser le format à succès de pyproject.toml, soit avec poetry, soit avec pdm. Je pense qu’il n’aurait pas fait le même bilan plaintif…
Bref, il veut pas apprendre un nouveau truc, trouve que le vieux truc pourri est pourri et prend le temps de faire un billet pour se plaindre, mais pas pour apprendre…
Posté par alkino .
Évalué à 5.
Dernière modification le 01 novembre 2023 à 15:55.
Pour sa défense :
Ça fait 4 fois que ça change et les 3 changements précédents étaient dans la douleur.
Et même quand il n'y avait pas de changement officiel ça pétait (en CI ou en prod).
On peut comprendre qu'au bout d'un certains moments les gens arrêtent de se mettre à jour tous les matins ou retardent le moment fatidique de la douleur.
Par exemple, le setup.py de mon projet fait 600 lignes avec des options dynamiques de compilation (python setup.py --enable-gpu-backend par exemple), on l'a déjà converti 2 fois (en se ratant au passage). Bref, marre. C'est pourri mais ça marche, j'ai plus le temps pour ça.
Donc pyproject.toml a très clairement gagné sur setup.cfg. Et je n'ai pas de chiffres là-dessus, mais je pense qu'une partie importante des setup.py restants (qui sont quand même descendus de 1259k à 922k) concernent des projets abandonnés ou "quick hacks" qui ne seront plus jamais touchés.
Un autre facteur objectif qui montre le succès de pyproject.toml, c'est que la plupart des autoformatters, linters & co. lisent désormais pyproject.toml. Par exemple, Black, qui est ultra-populaire, ne se configure que dans un pyproject.toml. Même chose pour Ruff ou pylint.
Sa remarque reste pourtant valable : « Le format le plus utilisé actuellement n’est ni le setup.cfg, ni le pyproject.toml, mais toujours le bon vieux setup.py. » (vrai en décembre 2018, vrai aujourd’hui…)
On peut supporter 922k projets abandonnés (vraiment ?), et cela pose de nombreuses questions sur la santé de l’écosystème. (si l’auteur du lien posté n’avait pas su trouver des solutions —et qu’on l’accuse de ne pas vouloir apprendre— peut-être qu’il aurait jeté l’éponge comme quelques boîtes autour de moi.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Ça fait 4 fois que ça change et les 3 changements précédents étaient dans la douleur.
Et même quand il n'y avait pas de changement officiel ça pétait (en CI ou en prod).
Voilà, c’est ce qui est dénoncé ; mais on réussi à retourner en
Bref, il veut pas apprendre un nouveau truc
On peut comprendre qu'au bout d'un certains moments les gens arrêtent de se mettre à jour tous les matins ou retardent le moment fatidique de la douleur.
Surtout quand, même en passant le cap, c’est pour se rendre compte que ce n’est pas du tout sec le nouveau truc et même que c’est un peu une régression vu qu’il a des fonctionnalités qui passent à la trappe.
En tout cas, je n’est pas eu l’impression que pyproject.toml permette de faire simplement ce qu’il faisait avec setup.py qui a en prime l’avantage d’être documenté (là il a fallu faire de l’ingénierie inverse.) Tout le contraire de
trouve que le vieux truc pourri est pourri et prend le temps de faire un billet pour se plaindre
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Pourtant le format de pyproject.toml est très bien documenté.
Je dis pas que tout est rose, je dis que le type se permet de prendre le temps de faire un billet pour se plaindre au lieu de se documenter correctement. C’est ça qui me gêne.
On n’a pas du lire le même billet car il est bien indiqué que « ce type » se documente et comment il s’est documenté (en plus en allant directement sur les références.) Je citerai juste un autre commentaire de quelqu’un qui a pris la peine de lire le billet :
on voit qu'il a dû se plonger dans le code source de setuptools pour comprendre comment la traduction était faite parce qu'elle est mal documentée, […]
Mais pour toi, faire ce boulot c’est ne pas se documenter correctement… wtf?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
poetry, ce ne serait pas trivial vu qu'il ne supporte pas les build backends arbitraires, et que son paquet contient une extension C, qu'il faudrait porter depuis setuptools. pdm, peut-être. Mais en fait, la question du frontend, poetry ou pdm ou pip ou build ou ce qu'on veut, n'est pas vraiment le problème ici : son extension C a des options de compilation, et de fait, aucun frontend n'interagit formidablement avec setuptools pour transmettre les options de compilation.
En tous cas, dans la section "How Does setuptools Handle --config-settings?" et sur ce commentaire GitHub, on voit qu'il a dû se plonger dans le code source de setuptools pour comprendre comment la traduction était faite parce qu'elle est mal documentée, et franchement, je pense qu'il a raison de s'en plaindre.
J'aurais été en partie d'accord avec toi si ça n'avait été qu'un projet en pur Python sans complexité de compilation. Mais là, il y a quand même de vrais problèmes tout à fait sérieux.
# Une horreur
Posté par alkino . Évalué à 4.
Dès qu'on a des projets qui compilent des libs pythons avec CMake ça devient l'horreur.
Je sais, j'ai essayé 3 fois.
Le build en python j'en peux plus. Je vais finir cet article, voir si j’apprends un truc nouveau.
# Pour faire court
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 1. Dernière modification le 01 novembre 2023 à 11:45.
La personne sait que
pyproject.tomlexiste, mais n’a pas voulu l’utiliser, parce que, selon lui, si ça marche faut pas corriger.Ensuite il explique comment il a galéré comme pas possible. J’ai envie de dire que le prédicat de départ était probablement faux et qu’il aurait dû utiliser le format à succès de
pyproject.toml, soit avecpoetry, soit avecpdm. Je pense qu’il n’aurait pas fait le même bilan plaintif…Bref, il veut pas apprendre un nouveau truc, trouve que le vieux truc pourri est pourri et prend le temps de faire un billet pour se plaindre, mais pas pour apprendre…
[^] # Re: Pour faire court
Posté par alkino . Évalué à 5. Dernière modification le 01 novembre 2023 à 15:55.
Pour sa défense :
Ça fait 4 fois que ça change et les 3 changements précédents étaient dans la douleur.
Et même quand il n'y avait pas de changement officiel ça pétait (en CI ou en prod).
On peut comprendre qu'au bout d'un certains moments les gens arrêtent de se mettre à jour tous les matins ou retardent le moment fatidique de la douleur.
Par exemple, le
setup.pyde mon projet fait 600 lignes avec des options dynamiques de compilation (python setup.py --enable-gpu-backendpar exemple), on l'a déjà converti 2 fois (en se ratant au passage). Bref, marre. C'est pourri mais ça marche, j'ai plus le temps pour ça.[^] # Re: Pour faire court
Posté par Pol' uX (site web personnel) . Évalué à 5.
Ça me rappelle ce post : https://sametmax2.com/vive-setup-cfg-et-mort-a-pyproject-toml/index.html
Adhérer à l'April, ça vous tente ?
[^] # Re: Pour faire court
Posté par alkino . Évalué à 3.
C'est exactement ça !
J'aime bien le :
On a pas transitionné vers la « nouvelle » solution qu'on a déjà la nouvelle. Mais les gens ne sont plus dupes :
Et les gens qui veulent me prouver que le nouveau format il est trop bien merci de venir avec du vrai packaging python pas des pets projects.
[^] # Re: Pour faire court
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
…pour un « format à succès » comme dirait le premier commentaire ; les chiffres disent le contraire de la croyance.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Pour faire court
Posté par jeanas . Évalué à 2.
Ho, attention, le post en question n'est pas daté, mais d'après le texte, il doit remonter aux tous premiers temps du
pyproject.toml.Aujourd'hui, la même chose donne
setup.py⇒ 922k résultats (https://github.com/search?q=path%3Asetup.py&type=code)setup.cfg⇒ 124k résultats (https://github.com/search?q=path%3Asetup.cfg&type=code)pyproject.toml⇒ 237k résultats (https://github.com/search?q=path%3Apyproject.toml&type=code)Donc
pyproject.tomla très clairement gagné sursetup.cfg. Et je n'ai pas de chiffres là-dessus, mais je pense qu'une partie importante dessetup.pyrestants (qui sont quand même descendus de 1259k à 922k) concernent des projets abandonnés ou "quick hacks" qui ne seront plus jamais touchés.Un autre facteur objectif qui montre le succès de
pyproject.toml, c'est que la plupart des autoformatters, linters & co. lisent désormaispyproject.toml. Par exemple, Black, qui est ultra-populaire, ne se configure que dans unpyproject.toml. Même chose pour Ruff ou pylint.[^] # Re: Pour faire court
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Sa remarque reste pourtant valable : « Le format le plus utilisé actuellement n’est ni le setup.cfg, ni le pyproject.toml, mais toujours le bon vieux setup.py. » (vrai en décembre 2018, vrai aujourd’hui…)
On peut supporter 922k projets abandonnés (vraiment ?), et cela pose de nombreuses questions sur la santé de l’écosystème. (si l’auteur du lien posté n’avait pas su trouver des solutions —et qu’on l’accuse de ne pas vouloir apprendre— peut-être qu’il aurait jeté l’éponge comme quelques boîtes autour de moi.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Pour faire court
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Voilà, c’est ce qui est dénoncé ; mais on réussi à retourner en
Surtout quand, même en passant le cap, c’est pour se rendre compte que ce n’est pas du tout sec le nouveau truc et même que c’est un peu une régression vu qu’il a des fonctionnalités qui passent à la trappe.
En tout cas, je n’est pas eu l’impression que
pyproject.tomlpermette de faire simplement ce qu’il faisait avecsetup.pyqui a en prime l’avantage d’être documenté (là il a fallu faire de l’ingénierie inverse.) Tout le contraire de“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Pour faire court
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 0.
Pourtant le format de pyproject.toml est très bien documenté.
Je dis pas que tout est rose, je dis que le type se permet de prendre le temps de faire un billet pour se plaindre au lieu de se documenter correctement. C’est ça qui me gêne.
[^] # Re: Pour faire court
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
On n’a pas du lire le même billet car il est bien indiqué que « ce type » se documente et comment il s’est documenté (en plus en allant directement sur les références.) Je citerai juste un autre commentaire de quelqu’un qui a pris la peine de lire le billet :
Mais pour toi, faire ce boulot c’est ne pas se documenter correctement… wtf?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Pour faire court
Posté par jeanas . Évalué à 3.
poetry, ce ne serait pas trivial vu qu'il ne supporte pas les build backends arbitraires, et que son paquet contient une extension C, qu'il faudrait porter depuis setuptools. pdm, peut-être. Mais en fait, la question du frontend, poetry ou pdm ou pip ou build ou ce qu'on veut, n'est pas vraiment le problème ici : son extension C a des options de compilation, et de fait, aucun frontend n'interagit formidablement avec setuptools pour transmettre les options de compilation.
En tous cas, dans la section "How Does setuptools Handle --config-settings?" et sur ce commentaire GitHub, on voit qu'il a dû se plonger dans le code source de setuptools pour comprendre comment la traduction était faite parce qu'elle est mal documentée, et franchement, je pense qu'il a raison de s'en plaindre.
J'aurais été en partie d'accord avec toi si ça n'avait été qu'un projet en pur Python sans complexité de compilation. Mais là, il y a quand même de vrais problèmes tout à fait sérieux.
[^] # Re: Pour faire court
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 1.
Merci enfin un commentaire pertinent !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.