Toolchain Roadmap#

Die Verwendung der SciPy-Bibliothek erfordert (oder hängt optional von) mehreren anderen Bibliotheken ab, um zu funktionieren. Die Hauptabhängigkeiten sind Python und NumPy. Zum Erstellen der Bibliothek oder zur Erstellung der Dokumentation wird eine größere Sammlung von Bibliotheken und Werkzeugen benötigt.

Selbstverständlich sind die Werkzeuge und Bibliotheken selbst nicht statisch. Dieses Dokument zielt darauf ab, einen Leitfaden dafür zu geben, wie die Verwendung dieser dynamischen Abhängigkeiten durch SciPy im Laufe der Zeit voranschreiten wird.

SciPy zielt darauf ab, mit einer Reihe von Versionen seiner abhängigen Bibliotheken und Werkzeuge kompatibel zu sein. Die Benutzerbasis zu zwingen, andere Komponenten für jede Veröffentlichung zu aktualisieren, würde den Wert von SciPy erheblich mindern. Die Abwärtskompatibilität mit sehr alten Werkzeugen/Bibliotheken aufrechtzuerhalten, schränkt jedoch die Möglichkeiten ein, welche neueren Funktionalitäten und Fähigkeiten integriert werden können. SciPy verfolgt einen etwas konservativen Ansatz und wahrt die Kompatibilität mit mehreren Hauptversionen von Python und NumPy auf den wichtigsten Plattformen. (Das kann an sich weitere Einschränkungen auferlegen. Siehe den Abschnitt C-Compiler als Beispiel.)

In erster Linie ist SciPy ein Python-Projekt, daher erfordert es eine Python-Umgebung.
BLAS und LAPACK numerische Bibliotheken müssen installiert sein.
Compiler für C, C++, Fortran-Code sind erforderlich, ebenso wie für Cython & Pythran (letzteres ist derzeit optional).
Die Python-Umgebung benötigt das Paket numpy installiert.
Das Testen erfordert die Python-Pakete pytest und hypothesis.
Das Erstellen der Dokumentation erfordert die Pakete matplotlib, Sphinx und MyST-NB zusammen mit dem PyData-Theme.

Die Werkzeuge, die zum Erstellen von CPython verwendet werden, haben einige Auswirkungen auf die Werkzeuge, die zum Erstellen von SciPy verwendet werden. Sie haben auch Auswirkungen auf die Beispiele, die in der Dokumentation verwendet werden (z. B. Docstrings für Funktionen), da diese Beispiele nur Funktionalitäten verwenden können, die in allen unterstützten Konfigurationen vorhanden sind.

SciPy erstellen#

Python-Versionen#

SciPy ist mit mehreren Python-Versionen kompatibel. Wenn die Unterstützung für ältere Python-Versionen eingestellt wird, orientiert sich SciPy an [NEP29]. Im Allgemeinen wird die Unterstützung für die älteste Python-Version 42 Monate nach der ursprünglichen Veröffentlichung eingestellt. Nach der Annahme von PEP 602 geschieht dies meist im April und wird von der Mitte des Jahres erfolgenden Veröffentlichung von SciPy aufgegriffen.

Python-Versionsunterstützung im Laufe der Zeit

Die Unterstützung für Python 2.7 wurde ab SciPy 1.3 eingestellt.

Datum	Unterstützte Pythons
2025	Py3.11+
2024	Py3.10+
2023	Py3.9+
2022	Py3.8+
2021	Py3.7+
2020	Py3.6+
2019	Py3.5+
2018	Py2.7, Py3.4+

NumPy#

SciPy hängt von NumPy ab, aber die Veröffentlichungen von SciPy sind nicht an die Veröffentlichungen von NumPy gebunden. SciPy versucht, mit mindestens den 4 vorherigen NumPy-Versionen kompatibel zu sein. Insbesondere kann sich SciPy nicht auf Funktionen nur des neuesten NumPy verlassen, sondern muss unter Verwendung dessen geschrieben werden, was in allen diesen 4 NumPy-Versionen üblich ist.

Python- und NumPy-Versionsunterstützung pro SciPy-Version

Die Tabelle zeigt die für jede SciPy-Nebenversion geeigneten NumPy- und Python-Versionen. Beachten Sie, dass nicht alle Patch-Versionen einer bestimmten Nebenversion von SciPy alle aufgeführten Python-Versionen unterstützen. Nur die neueste Patch-Version innerhalb jeder Nebenversion garantiert die Unterstützung aller aufgeführten Python-Versionen.

SciPy-Version	Python-Versionen	NumPy-Versionen
1.15	>=3.10, <3.14	>=1.23.5, <2.5.0
1.14	>=3.10, <3.14	>=1.23.5, <2.3.0
1.13	>=3.9, <3.13	>=1.22.4, <2.3.0
1.12	>=3.9, <3.13	>=1.22.4, <2.0.0
1.11	>=3.9, <3.13	>=1.21.6, <1.27.0
1.10	>=3.8, <3.12	>=1.19.5, <1.26.0
1.9	>=3.8, <3.12	>=1.18.5, <1.26.0
1.8	>=3.8, <3.11	>=1.17.3, <1.24.0
1.7	>=3.7, <3.11	>=1.16.5, <1.23.0
1.6	>=3.7, <3.10	>=1.16.5, <1.21.0
1.5	>=3.6, <3.10	>=1.14.5, <1.20.0
1.4	>=3.5, <3.9	>=1.13.3, <1.18.0
1.2	2.7, >=3.4, <3.8	>=1.8.2, <1.17.0

In spezifischen Fällen, z. B. für eine bestimmte Architektur, können diese Anforderungen variieren. Bitte überprüfen Sie die Release Notes und das Meta-Paket oldest-supported-numpy für weitere Informationen [OSN].

Compiler#

Zum Erstellen von SciPy werden Compiler für C, C++, Fortran sowie die Python-Transpiler Cython und Pythran benötigt (letzteres ist ab Version 1.7.0 eine optionale Abhängigkeit).

Um die Kompatibilität mit einer großen Anzahl von Plattformen und Setups aufrechtzuerhalten, insbesondere dort, wo die Verwendung der offiziellen Wheels (oder anderer Vertriebskanäle wie Anaconda oder conda-forge) nicht möglich ist, versucht SciPy, die Kompatibilität mit älteren Compilern auf Plattformen, die ihr offizielles Lebensende noch nicht erreicht haben, beizubehalten.

Wie unten detaillierter erläutert, sind die aktuellen minimalen Compiler-Versionen:

Compiler	Standardplattform (getestet)	Sekundäre Plattform (ungetestet)	Minimale Version
GCC	Linux	AIX, Alpine Linux, OSX	GCC 9.x
LLVM	OSX	Linux, FreeBSD, Windows	LLVM 12.x
MSVC	Windows		Visual Studio 2019 (vc142)

Beachten Sie, dass derzeit kein dedizierter CI-Job die minimal unterstützte LLVM/Clang-Version testet. Ältere Versionen als die in der SciPy CI verwendeten sollten funktionieren, solange sie den Kern (nicht-stdlib) C++17 unterstützen. Bitte reichen Sie ein Issue ein, wenn Sie beim Kompilieren auf ein Problem stoßen.

Offizielle Builds#

Derzeit werden SciPy-Wheels wie folgt erstellt:

Plattform	CI Basis Images	Compiler	Kommentar
Linux x86	`ubuntu-22.04`	GCC 10.2.1	`cibuildwheel`
Linux arm	`docker-builder-arm64`	GCC 11.3.0	`cibuildwheel`
OSX x86_64 (OpenBLAS)	`macos-12`	Apple clang 13.1.6/gfortran 11.3.0	`cibuildwheel`
OSX x86_64 (Accelerate)	`macos-13`	Apple clang 15.0.0/gfortran 13.2.0	`cibuildwheel`
OSX arm64 (OpenBLAS)	`macos-14`	Apple clang 15.0.0/gfortran 12.1.0	`cibuildwheel`
OSX arm64 (Accelerate)	`macos-14`	Apple clang 15.0.0/gfortran 13.2.0	`cibuildwheel`
Windows	`windows-2019`	GCC 10.3.0 (rtools)	`cibuildwheel`

Beachten Sie, dass die OSX-Wheels zusätzlich gfortran 11.3.0 für x86_64 und gfortran 12.1.0 für arm64 bündeln. Siehe tools/wheels/cibw_before_build_macos.sh.

C-Compiler#

SciPy ist mit den meisten modernen C-Compilern kompatibel (insbesondere clang). Heutzutage gibt es eine angemessene Unterstützung für aktuelle C-Sprachstandards über alle relevanten Compiler hinweg, obwohl dies sehr anders ist als früher. Die folgenden Absätze diskutieren hauptsächlich die Entwicklung dieser Einschränkungen; Leser, die sich nicht für den historischen Kontext interessieren, können zum Ende der Tabelle springen.

Historischer Kontext rund um ABI vs. Compiler-Unterstützung vs. C-Standards

In der Vergangenheit war der restriktivste Compiler auf relevanten Plattformen in Bezug auf C-Unterstützung der Microsoft Visual C++-Compiler und das Toolset (zusammen bekannt als MSVC; er hat ein kompliziertes Versionsschema) [MSVC]. Bis Visual Studio 2013 kam mit jeder MSVC-Version eine aktualisierte C Runtime (CRT)-Bibliothek, die mit den vorherigen inkompatibel war.

Dieser Mangel an Kompatibilität der Application Binary Interface (ABI) bedeutete, dass alle Projekte, die über diese Schnittstelle kommunizieren wollten (z. B. Aufruf einer Funktion aus einer Shared Library), mit derselben MSVC-Version (neu-)kompiliert werden mussten. Die lange Unterstützung von CPython 2.7 bedeutete, dass Python selbst lange Zeit bei VS 2008 feststeckte (um die ABI in Patch-Releases nicht zu brechen), und somit war auch SciPy auf dieser Version festgefahren.

Die Verwendung von VS 2008 (das keine Unterstützung für C99 hat) zum Kompilieren von Builds für CPython 2.7 bedeutete lange Zeit, dass C-Code in SciPy dem früheren C90-Standard für die Sprache und die Standardbibliothek entsprechen musste. Nach der Einstellung der Unterstützung für CPython 2.7 in SciPy 1.3.x wurde diese Einschränkung endlich aufgehoben (wenn auch zunächst nur schrittweise).

Mit der Einführung der „Universal C Runtime“ [UCRT] seit der Veröffentlichung von Visual Studio 2015 ist die ABI der C Runtime stabil, was bedeutet, dass die Einschränkung, dieselbe Compilerversion für SciPy wie für die zugrunde liegende CPython-Version verwenden zu müssen, nicht mehr zutrifft. Diese Stabilität ist jedoch nicht unbegrenzt: Microsoft plant seit einiger Zeit eine ABI-brechende Veröffentlichung – über den Compiler bzw. die C/C++-Standardbibliotheken – (vorläufig „vNext“ genannt), aber bisher ist unklar, wann diese eintreffen wird. Sobald dies geschieht, wird SciPy wieder auf höchstens die letzte ABI-kompatible Visual Studio-Version (derzeit VS 2022) beschränkt sein, bis alle gemäß NEP29 unterstützten CPython-Versionen mit vNext-kompatiblen Compilern von upstream kompiliert wurden.

Genauer gesagt gibt es eine Unterscheidung zwischen der Microsoft Visual Studio-Version und der Version des Ziel-„Toolset“, das als „Der Microsoft C++-Compiler, Linker, die Standardbibliotheken und zugehörige Dienstprogramme“ definiert ist. Jede Version von Visual Studio wird mit einer Standardversion des MSVC-Toolsets geliefert (z. B. VS2017 mit vc141, VS2019 mit vc142), aber es ist möglich, auch in neueren Versionen von Visual Studio ältere Toolsets zu verwenden. Aufgrund der Natur von Compilern (d. h. Aufteilung in Frontend und Backend) hängt es davon ab, ob der limitierende Faktor für die Unterstützung einer bestimmten Funktion (z. B. in C) auf die Version von Visual Studio oder das Toolset zurückzuführen ist, aber im Allgemeinen ist letzteres eine härtere Barriere und somit die effektive untere Grenze.

Dies liegt daran, dass, obwohl die ABI zwischen Toolset-Versionen stabil bleibt (bis vNext), alle Verknüpfungsoperationen ein Toolset verwenden müssen, das mindestens so neu ist wie das, das zum Erstellen der beteiligten Artefakte verwendet wurde. Das bedeutet, dass Toolset-Versionssprünge „infektiös“ wirken, d. h. alle konsumierenden Bibliotheken müssen ebenfalls ihre Toolset- (und wahrscheinlich Compiler-) Version aktualisieren. Dies ist eher ein Problem für NumPy als für SciPy, da letzteres nur eine kleine C-API hat und von weitaus weniger Projekten als NumPy kompiliert wird. Darüber hinaus bedeutet die Verwendung eines neueren Toolsets, dass Benutzer von Bibliotheken, die C++-Code kompilieren (wie SciPy), möglicherweise auch eine neuere Microsoft Visual C++ Redistributable benötigen, die ihnen verteilt werden muss.

Zusammenfassend lässt sich sagen, dass die Mindestanforderung für den MSVC-Compiler bzw. das Toolset pro SciPy-Version hauptsächlich durch die damals älteste unterstützte CPython-Version bestimmt wurde. Die erste SciPy-Version, die die Mindestanforderung darüber hinaus anhob, war SciPy 1.9, aufgrund der Einbeziehung des HiGHS-Submoduls, das nicht mit vc141 kompiliert (und die aggressive Entfernung von VS2017 in öffentlichen CI-Systemen, die es unmöglich macht, weiterhin sicherzustellen, dass alles überall mit nicht standardmäßigen Toolset-Versionen funktioniert).

SciPy-Version	CPython-Unterstützung	MS Visual C++	Toolset-Version
Bis 1.2	2.7 & 3.4+	VS 2008 (9.0)	vc90
1.3, 1.4	3.5+	VS 2010 (10.0)	vc100
1.5	3.6+	VS 2015 (14.0)	vc140
1.6, 1.7	3.7+	VS 2017 (14.1)	vc141
1.8	3.8+	VS 2017 (14.1)	vc141
1.9	3.8+	VS 2019 (14.20)	vc142

In Bezug auf C-Sprachstandards ist es wichtig zu beachten, dass C11 optionale Features hat (z. B. Atomare Operationen, Threading), von denen einige (VLAs & komplexe Typen) im C99-Standard obligatorisch waren. C17 (gelegentlich C18 genannt) kann als Bugfix für C11 betrachtet werden, daher kann C11 im Allgemeinen übersprungen werden.

SciPy war bei der Verwendung fortschrittlicherer Sprachfeatures durch die verfügbare Compilerunterstützung eingeschränkt, und insbesondere Microsoft hat sehr lange gebraucht, um die Konformität mit C99/C11/C17 zu erreichen. Ab Visual Studio 16.8 wird C11/C17 unterstützt (wenn auch ohne die C11-optionalen Features). C99 <complex.h> Unterstützung wäre besonders für SciPy interessant. Es ist jedoch immer noch möglich, komplexe Typen unter Windows zu verwenden, vorausgesetzt, es werden Windows-spezifische Typen verwendet.

Daher war die Verwendung von C-Features über C90 hinaus nur möglich, soweit Unterstützung unter Windows vorhanden war. Ende 2021 wird jedoch ein ausreichend aktueller Compiler verwendet. Dies liegt daran, dass GCC & LLVM alle relevanten C11-Features mit den ältesten derzeit verwendeten Versionen unterstützt und C17 nur ein Bugfix für C11 ist, wie oben erwähnt. Kurz gesagt:

Datum	C-Standard
<= 2018	C90
2019	C90 für alten Code, kann C99 für neuen Code in Betracht ziehen
2020	C99 (kein `<complex.h>`, `<stdatomic.h>`, `<threads.h>` & VLAs)
2021	C17 (kein `<complex.h>`, `<stdatomic.h>`, `<threads.h>` & VLAs)
?	C23, `<complex.h>`, `<stdatomic.h>`, …

C++-Sprachstandards#

C++-Sprachstandards für SciPy sind im Allgemeinen Richtlinien und keine offiziellen Entscheidungen. Dies gilt insbesondere für den Versuch, die Übernahmezeiten für neuere Standards vorherzusagen.

Datum	C++-Standard
<= 2019	C++03
2020	C++11
2021	C++14
2022	C++17 (Kernsprache + universell verfügbare stdlib-Features)
?	C++17 (mit vollständiger stdlib), C++20, C++23, C++26

Damit haben alle Hauptplattformen und ihre Compiler vergleichsweise aktuelle Versionen. SciPy hat sich jedoch historisch auch bemüht, weniger verbreitete Plattformen zu unterstützen – wenn auch nicht mit Binärartefakten (d. h. Wheels), dann zumindest dadurch, dass sie von der Quelle aus kompilierbar bleiben –, was beispielsweise AIX, Alpine Linux und FreeBSD einschließt.

Alle derzeit am niedrigsten unterstützten Compiler-Versionen (GCC 9, LLVM 14, VS2019 mit vc142) haben volle Unterstützung für die C++17 *Kernsprache*, die daher bedingungslos verwendet werden kann. Mitte 2024 ist jedoch die Unterstützung für die gesamte C++17-Standardbibliothek über alle Compiler hinweg noch nicht abgeschlossen [CPP], insbesondere bei LLVM. Daher ist es notwendig zu prüfen, ob ein bestimmtes stdlib-Feature von allen Compilern unterstützt wird, bevor es in SciPy verwendet werden kann.

Die C++20-Unterstützung stabilisiert sich sehr langsam, selbst abgesehen von Modulen, Coroutinen und mehreren noch nicht universell unterstützten stdlib-Features. Angesichts dessen, wie groß die C++20-Standard-Veröffentlichung war, wird erwartet, dass es noch eine Weile dauern wird, bis wir beginnen können, unseren Basissupport zu verschieben. Die Compilerunterstützung für C++23 und C++26 befindet sich noch in starker Entwicklung [CPP].

Fortran-Compiler#

Generell ist jeder gut gewartete Compiler wahrscheinlich geeignet und kann zum Erstellen von SciPy verwendet werden. Dennoch testen wir nicht mit alten gfortran-Versionen, weshalb wir die untere Grenze mit der für GCC oben übereinstimmend festlegen.

Werkzeug	Version
gfortran	>= 9.x
ifort/ifx	Eine aktuelle Version (nicht in CI getestet)
flang (LLVM)	>= 17.x

Cython & Pythran#

SciPy erfordert immer einen aktuellen Cython-Compiler. Seit 1.7 ist Pythran eine Build-Abhängigkeit (derzeit mit der Möglichkeit, sich abzumelden).

OpenMP-Unterstützung#

Aus verschiedenen Gründen kann SciPy nicht mit integrierter OpenMP-Unterstützung verteilt werden. Bei optionaler Pythran-Unterstützung kann beim Erstellen aus der Quelle OpenMP-aktivierter paralleler Code generiert werden.

Andere Bibliotheken#

Jede Bibliothek, die der BLAS/LAPACK-Schnittstelle entspricht, kann verwendet werden. OpenBLAS, ATLAS, MKL, BLIS und Referenz-Netlib-Bibliotheken sind bekannt dafür, zu funktionieren.

Bibliothek	Minimale Version
LAPACK	3.7.1
BLAS	Eine aktuelle Version von OpenBLAS, MKL oder ATLAS. Die Accelerate BLAS-Bibliothek wird nicht mehr unterstützt.

Es gibt einige zusätzliche optionale Abhängigkeiten.

Bibliothek	Version	URL
mpmath	Aktuell	http://mpmath.org/
scikit-umfpack	Aktuell	https://pypi.org/project/scikit-umfpack/
pooch	Aktuell	https://pypi.org/project/pooch/

Darüber hinaus unterstützt SciPy die Interaktion mit anderen Bibliotheken. Die Testsuite enthält zusätzliche Kompatibilitätstests, die ausgeführt werden, wenn diese installiert sind.

Werkzeug	Version	URL
pydata/sparse	Aktuell	pydata/sparse

Tests und Benchmarking#

Tests und Benchmarking erfordern aktuelle Versionen von

Werkzeug	Version	URL
pytest	Aktuell	https://docs.pytest.de/en/latest/
Hypothesis	Aktuell	https://hypothesis.readthedocs.io/
asv (airspeed velocity)	Aktuell	https://asv.readthedocs.io/

Erstellung der Dokumentation#

Werkzeug	Version
Sphinx	Welche neueren Versionen auch immer funktionieren. >= 5.0.
PyData Sphinx theme	Welche neueren Versionen auch immer funktionieren. >= 0.15.2.
Sphinx-Design	Welche neueren Versionen auch immer funktionieren. >= 0.4.0.
numpydoc	Welche neueren Versionen auch immer funktionieren. >= 1.5.0.
matplotlib	Im Allgemeinen werden >= 3.5 empfohlen.
MyST-NB	Welche neueren Versionen auch immer funktionieren. >= 0.17.1
jupyterlite-sphinx	Welche neueren Versionen auch immer funktionieren. >= 0.17.1
jupyterlite-pyodide-kernel	Welche neueren Versionen auch immer funktionieren. >= 0.1.0

Hinweis

Entwicklerhinweis: Die erforderlichen Versionen von numpy und matplotlib haben Auswirkungen auf die Beispiele in Python-Docstrings. Beispiele müssen sowohl in der Umgebung, die zum Erstellen der Dokumentation verwendet wird, als auch mit allen unterstützten Versionen von numpy/matplotlib ausführbar sein, die ein Benutzer mit dieser SciPy-Version verwenden könnte.

Paketierung#

Eine aktuelle Version von

Werkzeug	Version	URL
setuptools	Aktuell	https://pypi.org/project/setuptools/
wheel	Aktuell	https://pythonwheels.com
multibuild	Aktuell	matthew-brett/multibuild

Erstellung einer SciPy-Veröffentlichung und Verteilung enthalten Informationen zur Erstellung und Verteilung einer SciPy-Veröffentlichung.

Referenzen#

[CPP] (1,2,3)

https://cppreference.de/w/cpp/compiler_support

[MANY]

mayeut/pep600_compliance

[MSVC]

https://docs.microsoft.com/en-us/cpp/overview/visual-cpp-in-visual-studio

[NEP29]

https://numpy.org/neps/nep-0029-deprecation_policy.html

[OSN]

scipy/oldest-supported-numpy

[UCRT]

https://docs.microsoft.com/en-gb/cpp/windows/universal-crt-deployment