• # Une horreur

    Posté par  . É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  (site web personnel, Mastodon) . Évalué à 1. Dernière modification le 01 novembre 2023 à 11:45.

    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…

    • [^] # Re: Pour faire court

      Posté par  . É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.

      • [^] # Re: Pour faire court

        Posté par  (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  . Évalué à 3.

          C'est exactement ça !

          J'aime bien le :

          Une simple recherche github retourne :
          setup.py: 1,259,007 results
          setup.cfg: 165,716 results
          pyproject.toml: 2,137 results

          On a pas transitionné vers la « nouvelle » solution qu'on a déjà la nouvelle. Mais les gens ne sont plus dupes :

          Le packaging python si ça marche, tu touches pas. ™

          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  (site web personnel, Mastodon) . Évalué à 2.

            J'aime bien le :

            Une simple recherche github retourne :
            setup.py: 1,259,007 results
            setup.cfg: 165,716 results
            pyproject.toml: 2,137 results
            

            …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  (site web personnel, Mastodon) . É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.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.

              • [^] # Re: Pour faire court

                Posté par  (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  (site web personnel, Mastodon) . Évalué à 3.

        Ç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

        • [^] # Re: Pour faire court

          Posté par  (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  (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 :

            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

    • [^] # Re: Pour faire court

      Posté par  (site web personnel, Mastodon) . É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.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.