Les builds Windows de SciPy pour Python 3.12 salués comme un petit miracle

• Le build Windows de SciPy sur conda-forge a été disponible deux jours après la sortie de Python 3.12.0, si bien que la migration de SciPy vers Python 3.12 a pris quelques jours de retard, et non plusieurs mois
• Avec Python 3.12, distutils a été retiré de la bibliothèque standard, et SciPy a décidé de passer à l’outil de build Meson au lieu de numpy.distutils
• Meson devait refuser la combinaison MSVC+gfortran utilisée par conda-forge, et il n’existait pas sous Windows de compilateur Fortran gratuit compatible ABI que conda-forge puisse utiliser
• conda-forge anticipait que, s’il ne pouvait pas rebuilder SciPy sous Windows, la migration d’au moins environ 1 000 packages dépendant de SciPy serait retardée sur toutes les plateformes, ou qu’il faudrait exclure Windows de la migration Python
• LLVM 17.0 a été la première release à supprimer le flag -flang-experimental-exec de Flang, et Flang était estimé à un niveau de maturité « 0.8 »
• Après l’ajout de la prise en charge de llvm-flang dans Meson, le build et l’installation de SciPy ont réussi, et les tests sont passés à 100 % avec 54,987 passed, 2,866 skipped, 245 xfailed, 11 xpassed, 1 warning {p:100}

[GN⁺]

Avis de Hacker News

• C’était vraiment un excellent article, et je comprends maintenant pourquoi pip install échouait avec Python 3.12, mais l’avenir semble plus prometteur
  J’aime Python, mais cela aide aussi à comprendre pourquoi le packaging Python est un bazar malgré tout gérable
  La cause n’est pas Python lui-même, mais l’absence de standardisation des outils de build C/C++/Fortran et l’immensité de l’écosystème ; dans une certaine mesure, c’est une complexité irréductible
  Le simple fait que ça fonctionne tient presque du miracle

  • Oui, c’est bien là que se trouve la raison fondamentale de la complexité du packaging Python
    Le succès de Python tient en grande partie au fait qu’il a permis d’utiliser des paquets en langages mixtes essentiels, et les gestionnaires de paquets des autres langages grand public traitent très peu ce genre de problème
    Par exemple, cargo de Rust est excellent, mais il peut généralement partir du principe qu’il empaquette du code exclusivement Rust ; même si Rust est un langage compilé, le langage « possède » le compilateur, donc une stratégie de distribution avec build depuis les sources fonctionne
    Je ne sais pas comment cargo gère Fortran par défaut, mais si les principaux paquets cargo sous Windows exigeaient du code Fortran, j’ai du mal à imaginer que cela fonctionnerait bien
    La plus grande amélioration de l’écosystème Python a été la standardisation de wheel, le format de paquet binaire ; c’est seulement à partir de là que l’écosystème Python scientifique a vraiment commencé à prospérer sous Windows
    Cela dit, la compatibilité binaire est un énorme casse-tête, surtout quand on traverse les frontières entre langages et CPU
  • Dire que cela n’a rien à voir avec Python est discutable : si ces bindings FFI existent, c’est parce que Python est trop lent
  • Je suis d’accord avec l’idée que « le simple fait que ça fonctionne tient du miracle »
    La complexité des écosystèmes logiciels semble croître de manière exponentielle, et je me demande ce qui empêche au final un effondrement façon tour de Babel
    Bien sûr, ce n’est pas un problème propre au logiciel, mais c’en est un bon exemple
  • C’était vraiment un article qui ouvre les yeux
    On voit souvent des gens comparer leur gestionnaire de paquets favori à celui de Python et conclure que Python est nul, mais en réalité ce n’est pas le cas
    Ce que je comprends moins, en revanche, c’est pourquoi les gens de Python n’utilisent pas des bibliothèques mathématiques C/C++ au lieu de Fortran
  • Le vrai problème semble être que Python a tendance à attirer des personnes qui n’ont pas été formées au développement logiciel
    C’est un bazar empilé sur un autre bazar

• Quand Linux était un cas marginal brinquebalant, maintenu par des hackers vaguement coordonnés et parfois soumis à des contraintes idéologiques peu pratiques, il était fantastique que des gens brillants déploient d’énormes efforts pour le prendre en charge
  Mais maintenant que ce cas marginal brinquebalant est devenu un système propriétaire dont les contraintes relèvent presque de l’hostilité, exploité par des cyber-seigneurs, il est plus difficile de voir les efforts pour le prendre en charge d’un œil aussi positif qu’avant
  D’un côté, l’attention profonde portée à rendre ces outils accessibles à tous est vraiment admirable, et je salue ce travail
  Je ne dis absolument pas qu’il faudrait changer de direction ; c’est juste que cela fait réfléchir
  Avant, je me disais : « waouh, je suis vraiment content que ce travail avance » ; maintenant, je pense plutôt : « waouh, qu’auraient pu accomplir ces gens formidables s’ils n’avaient pas eu à se consacrer à cela ? »

  • En réalité, ce n’est pas forcément à eux de le faire
    Comme cela a été dit plusieurs fois, les développeurs de SciPy sont des bénévoles
    Une grande partie de l’histoire explique pourquoi SciPy ne pouvait qu’espérer que quelqu’un crée un compilateur Fortran open source pour Windows, et le salut semble surtout être venu de développeurs NVIDIA
  • Même cela n’est pas le point essentiel
    SciPy paie le prix de la décision stupide et très partiale des développeurs principaux de Python de choisir MSVC plutôt que MinGW comme chaîne d’outils pour Python sous Windows
    À mon avis, cette motivation vient du sponsoring de Microsoft
    La liste des développeurs principaux compte pas mal d’employés de Microsoft, qui sont payés par Microsoft pour y participer ; en plus, Microsoft prend aussi en charge les coûts des serveurs CI du projet CPython
    Si Python n’avait pas utilisé d’outils propriétaires dans sa chaîne d’outils, tout ce problème aurait pu être évité

• L’idée que « Meson aurait essayé de refuser la combinaison MSVC+gfortran utilisée dans conda-forge » ressemble à un bug
  À mon avis, le but d’un outil de build est d’exécuter les commandes qu’on lui donne, pas de bloquer en disant « désolé, Dave »

  • En réalité, c’est le linker MSVC qui se plaint
    Le problème est que les runtimes C utilisés par MSVC et gfortran, en particulier la propre bibliothèque runtime de gfortran, écrite en C, ne sont pas compatibles au niveau ABI
    Le contournement utilisé par NumPy consistait à linker les objets Fortran dans une DLL afin d’ajouter une couche d’indirection via une bibliothèque d’import, puis à amadouer MSVC
    Il fallait donc un travail supplémentaire pour créer ce type de DLL
    Il fallait le faire soit dans les fichiers de description du build, soit dans Meson, mais côté SciPy on ne voulait implémenter cette couche d’indirection ni d’un côté ni de l’autre, et les développeurs de Meson n’avaient pas non plus très envie d’aider activement
    Bien sûr, les développeurs de Meson ont apporté une aide générale, comme le support de Fortran et de Cython, mais ils ne voulaient pas fournir un échafaudage dangereux
    En pratique, c’était proche d’un hack, et cela ne fonctionnait par exemple que parce que la partie Fortran n’utilisait pas les fichiers ouverts côté Python/C
    https://web.archive.org/web/20180711144501/https://pav.iki.f...
  • L’article était bien écrit et détaillé, mais j’ai été un peu surpris par l’affirmation selon laquelle Meson est « largement utilisé pour les projets C et C++ »
    Personnellement, j’ai vu Bazel plus souvent que Meson
    Meson étant écrit en Python, il a dû sembler être un bon choix pour SciPy, et comme tout s’est finalement bien passé, c’est une bonne nouvelle
    Malgré toutes ses bizarreries, sa complexité et ses problèmes, je pense quand même que CMake reste proche du standard
  • Meson fait plus que simplement exécuter les commandes indiquées par l’utilisateur
    Il peut aussi synthétiser lui-même les commandes de façon à prendre en charge MSVC/gcc/clang
    Si on lui demande de synthétiser des commandes pour une combinaison qu’il ne connaît pas, il n’a évidemment pas d’autre choix que de répondre « désolé, Dave »
  • D’accord
    Je précise que je suis l’auteur d’un système de build concurrent de Meson qui sera bientôt publié
    Cela dit, le petit joyau méconnu de rant qui m’a fait prendre conscience de ce que je viens de dire, c’est [1]
    En résumé, un système de build doit exécuter les commandes que l’utilisateur lui demande d’exécuter, point final
    Parce que parfois, le programmeur sait vraiment ce qu’il fait
    J’ai un peu honte, mais avant de lire ce commentaire, je pensais rendre mon système de build magique
    Après l’avoir lu, j’ai compris que ce que les gens détestent dans les systèmes de build, c’est précisément cette « magie »
    [1]: https://ofekshilon.com/2016/08/30/cmake-rants/#comment-29273

• Je pensais que, pour ce genre de choses, tout le monde utilisait simplement WSL2 et n’en parlait plus
  Pourquoi vouloir absolument construire une version Windows native ?

  • C’est comme demander aux développeurs macOS pourquoi ils veulent des builds natifs au lieu de travailler dans une machine virtuelle Linux
    Travailler dans une machine virtuelle est peu pratique et offre une moins bonne intégration
  • Beaucoup plus de chercheurs qu’on ne l’imagine utilisent Windows
    Les étudiants aussi
  • Les grandes entreprises où il est presque impossible d’obtenir une machine qui ne soit pas sous Windows doivent constituer une base d’utilisateurs importante
  • Le fait que Microsoft et NVIDIA aient résolu les problèmes de pilotes CUDA dans WSL2 a vraiment été un salut
    Surtout quand on peut utiliser Docker Desktop par-dessus
    Cela permet de tirer le meilleur parti d’une situation qui n’est pas idéale

• Dans καταστροφή, κατα ne signifie pas « soudaineté », mais plutôt « vers le bas » ou « selon », avec une forte connotation de virage dans une mauvaise direction
  L’opposé de κατα est généralement ανα, mais αναστροφή signifie littéralement « rotation vers le haut » ou renversement
  Un meilleur néologisme serait donc peut-être ευστροφη, c’est-à-dire eustrophe, au sens de « bon tournant »
  Cela dit, si l’on parvenait à gagner un débat contre JRR Tolkien sur l’invention de mots, ce serait ευκαταστροφη, autrement dit un coup de chance
  Dans l’ensemble, j’aime le fait que cela saisisse une grâce débordante, de celles qui apportent joie et bonheur au monde

  • Le kata de katastrofi est en réalité plus proche de « against », si bien que katastrofi correspond au fait que les choses « tournent le dos »

• J’ai l’impression que les meilleurs BLAS sont pour la plupart en C
  Je pense à MKL, BLIS, OpenBLAS, ce genre de choses
  Je me demande jusqu’où on aurait pu aller avec seulement C et Python
  Je me demande aussi si, en partant aujourd’hui, on choisirait simplement libflame
  Bien sûr, SciPy comporte aussi beaucoup d’autres fonctionnalités, comme les méthodes itératives et les matrices creuses, donc il serait peut-être difficile d’éviter Fortran
  Cela dit, Fortran est un excellent langage, et je suis content que l’outillage sous Windows commence au moins à s’améliorer

  • La suppression de Fortran dans SciPy a été discutée plusieurs fois, mais pour les raisons évoquées plus haut, cela n’a pas avancé
    SciPy contient lui-même beaucoup de code Fortran, et le réécrire demanderait plusieurs années-personnes
    Une fois que cela est devenu possible, certaines parties clés qui utilisaient Fortran ont tout de même été supprimées
    Par exemple, celles liées aux FFT
  • Honnêtement, je ne pensais pas lire en 2023 la phrase « Fortran est un excellent langage, et je suis content que l’outillage sous Windows commence à s’améliorer »

• Excellent article
  Cette année, j’ai passé beaucoup de temps à moderniser un projet CMake C++ avec des bindings Python, puis à l’ajouter avec succès à conda-forge sous forme de nouveau feedstock, et je peux le dire avec assurance
  Si je deviens Dieu-empereur, ma première mesure liée à l’IT sera d’éradiquer Windows de tous les univers pour l’éternité

• Question très naïve, mais la sémantique de Fortran est-elle si différente qu’on ne puisse pas d’abord le convertir en C, puis le compiler avec un compilateur C ?
  Ensuite, on pourrait peut-être même maintenir le code en C ?
  Je n’imagine pas qu’il y ait beaucoup de développeurs Fortran pour maintenir ce genre de vieilles bibliothèques, mais il faut bien les maintenir, non ?

  • C’est possible si le ralentissement est acceptable
    Fortran n’a pas de pointeurs, seulement des tableaux, et les arguments de fonction ne peuvent pas avoir d’alias ; donc, si l’on met de côté l’horreur des blocs COMMON, les optimisations agressives et la vectorisation sont plus faciles
    Les bibliothèques mathématiques Fortran standard fonctionnent tout simplement bien et sont rapides
    En C/C++, on peut aussi écrire du code à vitesse équivalente, notamment avec le mot-clé restrict de C
    Mais convertir du code existant via une étape f2c dégrade souvent fortement les performances
  • Fortran est un langage de plus haut niveau que C
    Il y a largement assez de développeurs Fortran
    Il est horrible pour le développement d’applications, mais ce n’est pas le domaine principal de Fortran
  • Ça existe déjà
    f2c existe depuis des décennies
  • Exact, Fortran a des tableaux natifs

• J’ai une petite question : à ma connaissance, aarch64 et arm64, c’est la même chose
  Est-ce que je me trompe ?

  • C’est la même chose, mais autrefois il y avait deux implémentations LLVM concurrentes côté backend
    [1] https://www.phoronix.com/news/MTY5ODk
  • Lien indispensable : https://lkml.org/lkml/2012/7/15/133
  • Dans Python, d’après ce que je vois, aarch64 désigne généralement Linux, tandis que arm64 désigne généralement macOS ARM
    Je ne connais pas assez bien ce domaine pour comprendre pourquoi les noms diffèrent

• Les changements du système de build de Python sont vraiment difficiles à suivre
  Je serais aussi curieux de voir les chiffres de performance sous Windows
  Cela dit, ce n’est peut-être pas primordial au départ
  Les tâches sérieuses tourneront probablement sur des machines Linux

  • Heureusement, ça devrait désormais ralentir
    La grande transition a été de faire adopter PEP 517 par tout le monde, en particulier de migrer les projets Setuptools existants
  • Pour les calculs CPU purs, Windows est aussi rapide que Linux
    Parce que 99,9 % du temps, c’est le code utilisateur qui s’exécute, pas le système d’exploitation

[ahwjdekf]

Cela montre crûment à quel point on en est réduit à dépendre des langages compilés en binaire.

[kayws426]

Python l’a résolu, mais n’est-ce pas justement que les autres écosystèmes n’y sont pas parvenus ? C’est pour cela qu’ils fourniront sans doute des binaires précompilés.