Windows-SciPy-Builds für Python 3.12 gelten als kleines Wunder

• Die SciPy-Windows-Builds von conda-forge standen bereits zwei Tage nach der Veröffentlichung von Python 3.12.0 bereit, sodass die Python-3.12-Migration im SciPy-Ökosystem nicht monatelang blockiert war, sondern sich nur um wenige Tage verzögerte
• Mit der Entfernung von distutils aus der Standardbibliothek in Python 3.12 entschied sich SciPy, vom numpy.distutils-Ansatz auf das Build-Tool Meson zu wechseln
• Meson würde die von conda-forge verwendete Kombination aus MSVC+gfortran voraussichtlich ablehnen, und unter Windows gab es keinen freien ABI-kompatiblen Fortran-Compiler, den conda-forge nutzen konnte
• conda-forge erwartete, dass bei einem Scheitern des SciPy-Neuaufbaus unter Windows die Migration von mindestens etwa 1.000 SciPy-abhängigen Paketen auf allen Plattformen verzögert würde oder Windows bei der Python-Migration ausgeschlossen werden müsste
• LLVM 17.0 war die erste Veröffentlichung, in der Flang das Flag -flang-experimental-exec entfernte, und Flang wurde auf einen Reifegrad von „0.8 level maturity“ geschätzt
• Nach dem Hinzufügen der llvm-flang-Behandlung in Meson gelang der Build und die Installation von SciPy; die Tests bestanden mit 54,987 passed, 2,866 skipped, 245 xfailed, 11 xpassed, 1 warning zu 100 % {p:100}

[GN⁺]

Hacker-News-Kommentare

• Ein wirklich großartiger Artikel, und jetzt ist mir klar, warum pip install unter Python 3.12 gescheitert ist, aber die Zukunft wirkt heller.
  Ich mag Python, und es hat auch geholfen zu verstehen, warum Python-Paketierung ein beherrschbares Chaos ist.
  Die Ursache liegt nicht bei Python selbst, sondern in der fehlenden Standardisierung der Build-Tools für C/C++/Fortran und in der enormen Größe des Ökosystems; ein Teil dieser Komplexität ist wohl unvermeidbar.
  Dass das überhaupt funktioniert, grenzt an ein Wunder.

  • Genau, darin liegt der grundlegende Grund, warum Python-Paketierung so komplex ist.
    Der Erfolg von Python beruht zu einem großen Teil darauf, dass man zentrale gemischtsprachige Pakete nutzen konnte, und andere Mainstream-Sprachen mit Paketmanagern müssen sich mit diesem Problem kaum befassen.
    Rusts cargo ist zum Beispiel großartig, kann aber meist davon ausgehen, dass es um die Paketierung von reinem Rust-Code geht, und weil es eine kompilierte Sprache ist, die ihren Compiler selbst „besitzt“, funktioniert eine Distributionsstrategie mit Source-Builds.
    Ich weiß nicht, wie cargo standardmäßig mit Fortran umgeht, aber wenn unter Windows wichtige cargo-Pakete Fortran-Code benötigen würden, dürfte das kaum reibungslos funktionieren.
    Die größte Verbesserung im Python-Ökosystem war die Standardisierung des binären Paketformats wheel; erst dann begann das wissenschaftliche Python-Ökosystem unter Windows wirklich aufzublühen.
    Binärkompatibilität ist allerdings ein gewaltiger Problemfall, besonders wenn man sprach- und CPU-übergreifend arbeitet.
  • Ganz unabhängig von Python ist das nicht, denn der Grund, warum solche FFI-Bindings existieren, ist, dass Python zu langsam ist.
  • Ich stimme zu, dass „dass das überhaupt funktioniert, grenzt an ein Wunder“.
    Die Komplexität von Software-Ökosystemen scheint exponentiell zu wachsen, und ich frage mich, was am Ende verhindert, dass es zu einem babylonischen Kollaps kommt.
    Das gilt natürlich nicht nur für Software, ist aber ein gutes Beispiel.
  • Das war wirklich ein augenöffnender Artikel.
    Ich sehe oft, dass Leute ihren bevorzugten Paketmanager mit dem von Python vergleichen und dann zu dem Schluss kommen, Python sei miserabel, aber in Wirklichkeit ist das nicht so.
    Was ich allerdings nicht ganz verstehe, ist, warum die Python-Leute statt Fortran nicht mathematische C/C++-Bibliotheken verwenden.
  • Das eigentliche Problem scheint zu sein, dass Python dazu neigt, Menschen ohne Ausbildung in Softwareentwicklung anzuziehen.
    So stapelt sich Chaos auf noch mehr Chaos.

• Als Linux ein holpriger Randfall war, lose koordiniert von Hackern, die manchmal unter unpraktischen ideologischen Zwängen arbeiteten, war es fantastisch, wie brillante Leute enorm viel Mühe investierten, um Unterstützung dafür bereitzustellen.
  Aber jetzt ist dieser holprige Randfall ein proprietäres System geworden, dessen Einschränkungen fast schon feindselig wirken und das von Cyber-Feudalherren betrieben wird; deshalb fällt es mir schwerer, die Arbeit zu seiner Unterstützung noch so positiv zu sehen wie früher.
  Andererseits ist diese tiefe Fürsorge dafür, solche Werkzeuge für alle zugänglich zu machen, wirklich großartig, und dafür gebührt den Beteiligten Applaus.
  Ich sage keineswegs, dass man die Richtung ändern sollte, es gibt mir nur zu denken.
  Früher dachte ich: „Wow, zum Glück wird an dieser Arbeit gearbeitet“, heute denke ich eher: „Wow, was hätten diese brillanten Menschen erreicht, wenn sie sich nicht damit hätten beschäftigen müssen?“

  • Tatsächlich ist es nicht so, dass sie das unbedingt tun müssen.
    Wie mehrfach gesagt wurde, sind die SciPy-Entwickler Freiwillige.
    Ein Großteil des Textes erklärt, warum SciPy darauf angewiesen war, dass jemand einen Open-Source-Fortran-Compiler für Windows bereitstellt, und die Rettung scheint hauptsächlich von NVIDIA-Entwicklern gekommen zu sein.
  • Auch das ist noch nicht der Kern des Problems.
    SciPy zahlt gerade den Preis für die törichte und stark voreingenommene Entscheidung der Python-Core-Entwickler, unter Windows MSVC statt MinGW als Toolchain für Python zu wählen.
    Ich vermute, die Motivation dafür lag im Microsoft-Sponsoring.
    Auf der Liste der Core-Entwickler stehen einige Microsoft-Mitarbeiter; sie werden von Microsoft dafür bezahlt, auf dieser Liste mitzuwirken, und außerdem trägt Microsoft auch die Kosten für die CI-Server des CPython-Projekts.
    Wenn Python für seine Toolchain keine proprietären Werkzeuge verwendet hätte, hätte sich dieses ganze Problem vermeiden lassen.

• Dass „Meson die bei conda-forge verwendete Kombination aus MSVC+gfortran ablehnen wollte“, klingt nach einem Bug
  Der Zweck eines Build-Tools ist es doch, die angewiesenen Befehle auszuführen, und nicht mit „Es tut mir leid, Dave“ den Weg zu versperren

  • Tatsächlich beschwert sich hier der MSVC-Linker
    Das Problem ist die von MSVC und gfortran verwendete C-Laufzeit, insbesondere dass die gfortran-Laufzeitbibliothek selbst in C geschrieben ist und die beiden ABI-seitig nicht kompatibel sind
    Der von NumPy verwendete Workaround bestand darin, die Fortran-Objekte in eine DLL zu linken und mit einer Importbibliothek als indirekter Zwischenschicht zu arbeiten, um MSVC zu besänftigen
    Dafür war also zusätzliche Arbeit nötig, um solche DLLs zu erstellen
    Ob man das nun in den Build-Beschreibungsdateien oder in Meson macht, es musste so oder so gemacht werden, aber auf SciPy-Seite wollte man diese Zwischenschicht an keiner der beiden Stellen implementieren, und auch die Meson-Entwickler wollten dabei nicht besonders aktiv helfen
    Natürlich haben die Meson-Entwickler allgemeiner bei Dingen wie Fortran- und Cython-Unterstützung geholfen, aber sie wollten keine unsichere Konstruktion bereitstellen
    Tatsächlich war das eher ein Hack und funktionierte zum Beispiel nur deshalb, weil die Fortran-Seite keine von Python/C geöffneten Dateien benutzte
    https://web.archive.org/web/20180711144501/https://pav.iki.f...
  • Der Artikel war gut geschrieben und detailreich, aber die Behauptung, Meson werde „weit verbreitet für C- und C++-Projekte verwendet“, hat mich etwas überrascht
    Persönlich habe ich Bazel öfter gesehen als Meson
    Vermutlich schien Meson eine gute Wahl für SciPy zu sein, weil es in Python geschrieben ist, und da es am Ende gut geklappt hat, kann man nur gratulieren
    Trotzdem halte ich CMake trotz all der Eigenheiten, Komplexität und Probleme immer noch für etwas, das dem Standard am nächsten kommt
  • Meson macht mehr, als einfach nur die vom Benutzer angegebenen Befehle auszuführen
    Es kann die Befehle selbst zusammensetzen, um MSVC/gcc/clang zu unterstützen
    Wenn man verlangt, dass es für eine ihm unbekannte Kombination einen Befehl zusammensetzt, kann es natürlich nur mit „Es tut mir leid, Dave“ antworten
  • Stimme zu
    Der Vollständigkeit halber: Ich bin der Autor eines mit Meson konkurrierenden Build-Systems, das bald veröffentlicht wird
    Die kleine, kaum bekannte, aber brillante Tirade unter [1] hat mir allerdings genau das klargemacht, was ich eben beschrieben habe
    Kurz gesagt: Ein Build-System sollte die Befehle ausführen, die der Benutzer ausführen lassen will, und sonst nichts
    Manchmal weiß der Programmierer tatsächlich genau, was er tut
    Es ist mir fast peinlich, aber bevor ich diesen Kommentar gelesen hatte, wollte ich mein Build-System möglichst magisch machen
    Danach wurde mir klar, dass genau diese „Magie“ der Grund ist, warum Leute Build-Systeme hassen
    [1]: https://ofekshilon.com/2016/08/30/cmake-rants/#comment-29273

• Ich dachte, so etwas erledigt heute einfach jeder mit WSL2
  Warum will man überhaupt noch eine native Windows-Version bauen?

  • Das ist so, als würde man macOS-Entwickler fragen, warum sie keinen nativen Build wollen und stattdessen einfach in einer Linux-VM arbeiten
    In einer VM zu arbeiten ist unbequem und weniger integriert
  • Viel mehr Forschende als man denkt benutzen Windows
    Studierende auch
  • Vermutlich sind Großunternehmen, in denen es nahezu unmöglich ist, Nicht-Windows-Hardware zu bekommen, eine wichtige Nutzergruppe
  • Dass Microsoft und NVIDIA die CUDA-Treiber-Probleme unter WSL2 gelöst haben, ist wirklich eine Rettung
    Besonders dann, wenn man darauf Docker Desktop verwenden kann
    Das ist das Beste, was man aus einer nicht idealen Situation herausholen kann

• Das κατα in καταστροφή bedeutet eher nicht „Plötzlichkeit“, sondern eher „nach unten“ oder „entsprechend“, mit einer starken Konnotation, dass etwas in eine schlechte Richtung kippt
  Das Gegenteil von κατα ist gewöhnlich ανα, aber αναστροφή bedeutet wörtlich eher „nach oben drehen“ oder Umkehrung
  Daher wäre ευστροφη, also eustrophe, vielleicht die bessere Neubildung für eine „gute Wendung“
  Wenn man allerdings eine Debatte mit JRR Tolkien über Wortschöpfungen gewinnt, dann wäre das ευκαταστροφη, also pures Glück
  Insgesamt gefällt mir, dass hier überströmende Gnade eingefangen wird und dass so etwas Freude und Glück in die Welt bringt

  • Das kata in katastrofi ist eigentlich näher an „against“, daher entspricht katastrofi eher dem Gedanken, dass Dinge einem „den Rücken zukehren“

• Ich habe den Eindruck, dass die besten BLAS größtenteils in C geschrieben sind
  Dinge wie MKL, BLIS und OpenBLAS
  Ich frage mich, wie weit man nur mit C und Python gekommen wäre
  Und wenn man heute neu anfangen würde, ob man dann einfach libflame wählen würde
  Natürlich hat SciPy noch viele andere Funktionen wie iterative Verfahren, Sparse-Matrizen usw., daher lässt sich Fortran vielleicht nicht leicht vermeiden
  Trotzdem ist Fortran eine großartige Sprache, und es ist gut zu sehen, dass sich die Tooling-Situation unter Windows zumindest zu verbessern beginnt

  • Es gab ein paar Diskussionen darüber, Fortran aus SciPy zu entfernen, aber aus den bereits genannten Gründen kam das nie wirklich voran
    Auch in SciPy selbst steckt viel Fortran-Code, und ein Neuschreiben würde Arbeitskraft über Jahre hinweg erfordern
    Nachdem das möglich geworden war, wurden einige Kernbereiche, die früher Fortran nutzten, tatsächlich entfernt
    Zum Beispiel Teile rund um FFT
  • Ehrlich gesagt hätte ich nicht gedacht, 2023 einmal den Satz zu lesen: „Fortran ist eine großartige Sprache, und es ist gut zu sehen, dass sich die Tooling-Situation unter Windows zu verbessern beginnt“

• Großartiger Artikel
  Ich habe dieses Jahr viel Zeit damit verbracht, ein CMake-C++-Projekt mit Python-Bindings zu modernisieren, und nachdem ich es erfolgreich als neuen Feedstock zu conda-forge hinzugefügt habe, kann ich mit Überzeugung sagen:
  Wenn ich göttlicher Kaiser würde, wäre meine erste IT-Maßnahme, Windows in allen Universen für immer auszurotten

• Vielleicht eine sehr naive Frage, aber ist die Fortran-Semantik so anders, dass man den Code nicht zuerst nach C übersetzen und dann mit einem C-Compiler kompilieren kann?
  Danach könnte man ihn doch vielleicht auch in C weiterpflegen?
  Es scheint nicht so, als gäbe es viele Fortran-Leute, die solche alten Bibliotheken warten, aber Wartung braucht es doch trotzdem, oder?

  • Wenn es langsamer werden darf, ist das möglich
    Fortran hat keine Pointer, sondern nur Arrays, und Funktionsargumente dürfen kein Aliasing haben. Wenn man also einmal den Schrecken der COMMON-Blöcke beiseitelässt, sind aggressive Optimierung und Vektorisierung leichter
    Standard-Fortran-Mathematikbibliotheken funktionieren einfach gut und sind schnell
    Auch in C/C++ kann man Code mit vergleichbarer Geschwindigkeit schreiben, insbesondere in C mit dem Schlüsselwort restrict
    Aber wenn man bestehenden Code durch einen f2c-Schritt konvertiert, bricht die Performance in vielen Fällen deutlich ein
  • Fortran ist eine höherstufige Sprache als C
    Es gibt auch durchaus genug Fortran-Entwickler
    Für die Anwendungsentwicklung ist es schrecklich, aber das ist auch nicht das Hauptgebiet von Fortran
  • So etwas gibt es bereits
    f2c existiert seit Jahrzehnten
  • Stimmt, Fortran hat native Arrays

• Eine kleine Nebenfrage: Soweit ich weiß, sind aarch64 und arm64 dasselbe
  Liege ich da falsch?

  • Es ist dasselbe, aber früher gab es im Backend zwei konkurrierende LLVM-Implementierungen
    [1] https://www.phoronix.com/news/MTY5ODk
  • Pflichtlink: https://lkml.org/lkml/2012/7/15/133
  • In Python bezeichnet aarch64, soweit ich das sehe, meistens Linux, und arm64 meistens macOS ARM
    Ich kenne mich in dem Bereich nicht gut genug aus, um zu verstehen, warum die Namen unterschiedlich sind

• Die Änderungen am Build-System von Python sind wirklich schwer nachzuverfolgen
  Mich würden auch die Performance-Zahlen unter Windows interessieren
  Wobei das vielleicht zunächst nicht so wichtig ist
  Ernsthafte Arbeit wird vermutlich ohnehin auf einer Linux-Maschine laufen

  • Zum Glück dürfte es jetzt ruhiger werden
    Die große Umstellung bestand darin, alle dazu zu bringen, PEP 517 zu übernehmen, insbesondere bestehende Setuptools-Projekte umzustellen
  • Bei reinen CPU-Berechnungen ist Windows genauso schnell wie Linux
    Denn 99,9 % der Zeit läuft nicht das Betriebssystem, sondern User-Code

[ahwjdekf]

Das ist ein Fall, in dem schonungslos offengelegt wird, wie sehr man von binär kompilierten Sprachen verdammt noch mal abhängig ist.

[kayws426]

Hat Python das Problem gelöst, andere Ökosysteme aber nicht? Deshalb wird man wohl vorab kompilierte Binärdateien bereitstellen.