Le build de SciPy pour Python 3.12 sur Windows considéré comme un petit miracle

Pourquoi le build de SciPy pour Python 3.12 tient du miracle

• La version 3.12 de Python a été publiée récemment.
• Il est courant que les principaux paquets publient rapidement des versions compatibles avec une nouvelle version de Python.
• La publication par SciPy d’un build compatible avec Python 3.12 est le résultat heureux d’un alignement de plusieurs calendriers.

Le rôle de Fortran et des compilateurs

• Fortran est un langage de programmation important depuis les années 1950, et de nombreux codes scientifiques sont écrits en Fortran.
• Il existait divers compilateurs Fortran, mais ils étaient tous propriétaires.
• Un compilateur transforme le code écrit par les programmeurs en une forme exécutable par l’ordinateur.
• GCC est un compilateur librement utilisable qui prend en charge diverses architectures CPU et systèmes d’exploitation.

Python et les problèmes de performance

• Python peut être utilisé sans compilateur, mais il est plus lent que les langages compilés.
• Lorsque les performances sont importantes, une bonne solution consiste à utiliser du code compilé tout en l’enveloppant avec une interface Python.
• NumPy et SciPy utilisent du code Fortran pour les performances, ce qui implique que les utilisateurs ont besoin d’un compilateur lors de l’installation du paquet.

Les problèmes du packaging Python

• Le packaging Python a dû être continuellement réinventé à cause de sa complexité.
• Télécharger directement le code source pose des problèmes aux utilisateurs, comme la nécessité de configurer un compilateur et des temps de build longs.
• Le format "wheel" a amélioré la situation en distribuant les paquets avec les bibliothèques nécessaires incluses.

L’émergence de conda et conda-forge

• conda propose une approche plus globale qui inclut tout le nécessaire au packaging.
• conda-forge est un canal piloté par la communauté qui prend en charge le travail d’intégration des paquets.
• conda-forge cherche à prendre en charge toutes les plateformes courantes et fonctionne grâce à des bénévoles.

Le choix de Meson comme outil de build pour SciPy

• SciPy a choisi Meson comme outil de build.
• Meson propose une interface dans le style de Python et est moins complexe que CMake.
• Meson suit une philosophie de conception qui n’autorise pas les mauvaises pratiques pour les utilisateurs non experts.

Le renouveau de Fortran et LLVM

• L’intérêt pour Fortran a augmenté ces dernières années.
• Le développement de nouveaux compilateurs Fortran basés sur LLVM s’est accéléré.
• LLVM fournit une infrastructure de compilation fonctionnant sur diverses architectures et plateformes.

La transition de SciPy vers Meson et les problèmes de conda-forge

• SciPy est passé à Meson, mais des problèmes sont apparus en raison de l’absence de compilateur Fortran pour Windows.
• conda-forge a dû reconstruire tous les paquets concernés pour la migration vers Python 3.12.

Le sens de la « yukatastrophe » et l’avis de GN⁺

• La suite de tests de SciPy est passée à 100 %, ce qui a permis un build de SciPy compatible avec Python 3.12 sur conda-forge.
• C’est le résultat d’une combinaison d’efforts et de coïncidences heureuses, qui apporte un bénéfice important à la communauté Python.
• Avis de GN⁺ : cet article montre comment les efforts et la collaboration de la communauté Python peuvent résoudre des problèmes techniques complexes. La sortie réussie par SciPy d’un build compatible avec Python 3.12 constitue une avancée importante dans le domaine du calcul scientifique, et symbolise la puissance de l’open source et de la communauté.

[GN⁺]

Commentaires sur Hacker News

• La communauté du logiciel libre devrait cesser de prendre en charge le système d’exploitation de Microsoft et les laisser porter eux-mêmes des choses comme scipy

  • Ceux qui ont besoin de Linux peuvent le trouver avec WSL2
  • Microsoft devrait inclure un compilateur dans le système d’exploitation, comme tous les autres éditeurs de systèmes d’exploitation l’ont fait pendant 60 ans

• La complexité du packaging Python vient de la non-standardisation des outils de build C/C++/Fortran et de l’énormité de l’écosystème, et non de Python lui-même

  • C’est une complexité qu’on ne peut pas réduire
  • Le simple fait que le système de packaging Python fonctionne est en soi un miracle

• Le fait que l’outil de build Meson refuse la combinaison MSVC+gfortran ressemble à un bug

  • Le but d’un outil de build est d’exécuter les commandes demandées par l’utilisateur, pas de les lui refuser

• Beaucoup de gens résolvent le problème en utilisant WSL2, et cela amène à se demander pourquoi vouloir construire une version Windows native

• La plupart des meilleures bibliothèques BLAS sont écrites en C, et on se demande jusqu’où on pourrait aller avec seulement du C et du Python

  • Le Fortran est peut-être inévitable, mais il est encourageant de voir commencer des améliorations des outils Fortran sous Windows

• Question naïve sur le fait que la sémantique du Fortran est trop différente de celle du C pour permettre une conversion vers du C puis une compilation avec un compilateur C, et sur la possibilité d’assurer la maintenance en C

  • On suppose qu’il n’y a pas beaucoup d’experts Fortran pour maintenir ces anciennes bibliothèques, alors qu’une maintenance est nécessaire

• Il est difficile de suivre les évolutions du système de build de Python

  • Curiosité à propos des chiffres de performance sous Windows, mais on s’attend à ce que la plupart des tâches sérieuses tournent sur des machines Linux

• Question sur le fait de savoir si "aarch64" et "arm64" sont la même chose

  • Sur Wikipedia, ARM64 redirige vers AArch64

• Le Fortran était la cible de blagues dans les services informatiques, mais il a connu un retour spectaculaire ces dernières années

  • Les raisons de ce retour ne sont pas claires, mais les liens associés permettent de mieux le comprendre

• Question sur la différence entre "arm64" et "aarch64" dans le tableau compilateur/architecture

  • Mention du fait que l’article ARM64 de Wikipedia redirige vers AArch64

[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.