Entwicklungslandschaft

iOS bietet eine einzige API, aber 2 verschiedene ABIs – iphoneos (physische Geräte) und iphonesimulator. Jede dieser ABIs kann auf mehreren CPU-Architekturen bereitgestellt werden. Zum Zeitpunkt der Erstellung unterstützt Apple offiziell arm64 für die Geräte-ABI und arm64 und x86_64 für die Simulator-ABI.

Wie macOS unterstützt auch iOS die Erstellung von „Fat“-Binärdateien, die mehrere CPU-Architekturen enthalten. Fat-Binärdateien *können* jedoch keine ABIs umfassen. Das heißt, es ist möglich, eine Fat-Simulator-Binärdatei und eine Fat-Geräte-Binärdatei zu haben, aber es ist nicht möglich, eine einzelne Fat-„iOS“-Binärdatei zu erstellen, die sowohl Simulator- als auch Geräteanforderungen abdeckt. Zur Verteilung eines einzigen Entwicklungsartefakts verwendet Apple eine „XCframework“-Struktur – einen Wrapper um mehrere ABIs, die eine gemeinsame API implementieren.

iOS läuft auf einem Darwin-Kernel, ähnlich wie macOS. Es besteht jedoch die Notwendigkeit, macOS und iOS auf Implementierungsebene zu unterscheiden, da es erhebliche Plattformunterschiede zwischen iOS und macOS gibt.

iOS-Code wird für die Kompatibilität mit einer minimalen iOS-Version kompiliert.

Apple bezieht sich in seinen Marketingmaterialien häufig auf „iPadOS“. Aus Entwicklungssicht gibt es jedoch keinen erkennbaren Unterschied zwischen iPadOS und iOS. Eine Binärdatei, die für die iphoneos- oder iphonesimulator-ABIs kompiliert wurde, kann auf iPads bereitgestellt werden.

Andere Apple-Plattformen wie tvOS, watchOS und visionOS verwenden andere ABIs und sind nicht Gegenstand dieser PEP.

POSIX-Konformität

iOS ist im Grunde eine POSIX-Plattform. Ähnlich wie bei WASI/Emscripten gibt es jedoch POSIX-APIs, die auf iOS existieren, aber nicht verwendet werden können; und POSIX-APIs, die überhaupt nicht existieren.

Das Bemerkenswerteste daran ist, dass iOS keine Form der Mehrprozessunterstützung bietet. fork und spawn *existieren* zwar in der iOS-API; wenn sie jedoch aufgerufen werden, stoppt der aufrufende iOS-Prozess, und der neue Prozess startet nicht.

Im Gegensatz zu WASI/Emscripten wird Threading unter iOS unterstützt.

Es gibt auch erhebliche Einschränkungen bei der Socket-Handhabung. Aufgrund der Sandbox-Beschränkungen von Prozessen ist keine Interprozesskommunikation über Sockets möglich. Sockets für die Netzwerkommunikation sind jedoch verfügbar.

Dynamische Bibliotheken

Die App Store-Richtlinien von iOS erlauben die Entwicklung von Apps in anderen Sprachen als Objective C oder Swift. Sie enthalten jedoch sehr strenge Richtlinien für die Struktur von Apps, die zur Verteilung eingereicht werden.

iOS-Apps können dynamisch geladene Bibliotheken verwenden; es gibt jedoch sehr strenge Anforderungen, wie dynamisch geladener Inhalt für die Verwendung unter iOS verpackt werden muss.

• Dynamische Binärinhalte müssen als dynamische Bibliotheken kompiliert werden, nicht als Shared Objects oder Binärpakete.
• Sie müssen im App-Bundle als Frameworks verpackt werden.
• Jedes Framework kann nur eine einzige dynamische Bibliothek enthalten.
• Das Framework *muss* im Ordner Frameworks der iOS-App enthalten sein.
• Ein Framework darf keinen Nicht-Bibliotheksinhalt enthalten.

Dies schränkt die Funktionsweise von CPython ein. Es ist nicht möglich, Binärmodule in den Ordnern lib-dynload und/oder site-packages zu speichern; sie müssen im Frameworks-Ordner der App gespeichert werden, wobei jedes Modul in einem Framework verpackt ist. Dies bedeutet auch, dass die gängige Annahme, dass ein Python-Modul den Speicherort eines Binärmoduls mithilfe des __file__-Attributs des Python-Moduls konstruieren kann, nicht mehr gilt.

Wie bei macOS erfordert die Kompilierung eines Binärmoduls, das von einem statisch verknüpften Python-Build aus zugänglich ist, die Verwendung der Option --undefined dynamic_lookup, um libpython3.x in jedes Binärmodul zu verknüpfen. Unter iOS löst diese Compiler-Flagge jedoch eine Deprecation-Warnung aus, wenn sie verwendet wird. Eine Warnung dieser Flagge wurde auch unter macOS beobachtet – jedoch deuten Antworten von Apple-Mitarbeitern darauf hin, dass sie nicht beabsichtigen, das CPython-Ökosystem durch Entfernen dieser Option zu beeinträchtigen. Da Python derzeit keine nennenswerte Präsenz unter iOS hat, ist es schwierig zu beurteilen, ob die iOS-Nutzung dieser Flagge unter dieselbe Kategorie fällt.

Konsolen- und interaktive Nutzung

Die Verteilung einer traditionellen CPython REPL oder eines interaktiven „python.exe“ sollte nicht als Ziel dieser Arbeit betrachtet werden.

Mobile Geräte (einschließlich iOS) bieten keine TTY-artige Konsole. Sie bieten keine stdin, stdout oder stderr. iOS bietet ein Systemprotokoll, und es ist möglich, eine Umleitung zu installieren, sodass alle stdout- und stderr-Inhalte an das Systemprotokoll umgeleitet werden; es gibt jedoch kein Analogon für stdin.

Darüber hinaus schränkt iOS das Herunterladen von zusätzlichem Code zur Laufzeit ein (da dieses Verhalten funktional nicht von dem Versuch, die App Store-Überprüfung zu umgehen, zu unterscheiden wäre). Infolgedessen wird eine traditionelle Entwicklungserfahrung mit „virtueller Umgebung erstellen und pip installieren“ unter iOS nicht praktikabel sein.

Es ist *möglich*, eine native iOS-Anwendung zu erstellen, die eine REPL-Schnittstelle bereitstellt. Dies wäre näher an einer IDLE-ähnlichen Benutzererfahrung; Tkinter kann jedoch unter iOS nicht verwendet werden, sodass jede App eine Neuentwicklung von Grund auf erfordern würde. Der iOS App Store enthält bereits mehrere Beispiele für Apps in dieser Kategorie (z. B. Pythonista und Pyto). Der Schwerpunkt dieser Arbeit wäre die Bereitstellung einer eingebetteten Distribution, die IDE-ähnliche native Schnittstellen nutzen könnten, und nicht eine benutzerorientierte „App“-Schnittstelle zu iOS unter Python.

Plattformerfassung

Subprozessunterstützung

iOS wird das Muster zur Deaktivierung von Subprozessen nutzen, das von WASI/Emscripten etabliert wurde. Das subprocess-Modul löst eine Ausnahme aus, wenn versucht wird, einen Subprozess zu starten, und os.fork- und os.spawn-Aufrufe lösen eine OSError aus.

Dynamisches Laden von Modulen

Um das dynamische Laden unter iOS zu unterstützen, wird der importlib-Bootstrap erweitert, um einen Metapath-Finder hinzuzufügen, der eine Anfrage nach einem Python-Binärmodul in einen Framework-Speicherort umwandeln kann. Dieser Finder wird nur installiert, wenn sys.platform == "ios".

Dieser Finder wandelt einen Python-Modulnamen (z. B. foo.bar._whiz) in einen eindeutigen Framework-Namen um, indem er den vollständigen Modulnamen als Framework-Namen verwendet (d. h. foo.bar._whiz.framework). Ein Framework ist ein Verzeichnis; der Finder sucht in diesem Verzeichnis nach einer Binärdatei namens foo.bar._whiz.

Kompilierung

Das einzige unterstützte Binärformat ist eine dynamisch verknüpfbare libpython3.x.dylib, die in einem iOS-kompatiblen Framework-Format verpackt ist. Während die Compiler-Option --undefined dynamic_lookup derzeit funktioniert, ist die langfristige Machbarkeit der Option nicht garantiert. Anstatt sich auf eine Compiler-Flagge mit ungewisser Zukunft zu verlassen, werden Binärmodule unter iOS mit libpython3.x.dylib verknüpft. Das bedeutet, dass iOS-Binärmodule nicht von einer ausführbaren Datei geladen werden können, die statisch mit libpython3.x.a verknüpft wurde. Daher wird eine statische libpython3.x.a iOS-Bibliothek nicht unterstützt. Dies ist dasselbe Muster, das von CPython unter Windows verwendet wird.

Das Kompilieren von CPython für iOS erfordert die Verwendung der plattformübergreifenden Werkzeuge im configure-Build-System von CPython. Ein einzelner configure/make/make install-Durchlauf erzeugt ein Python.framework-Artefakt, das für eine einzelne ABI und Architektur verwendet werden kann.

Zusätzliche Werkzeuge werden benötigt, um die Python.framework-Builds für mehrere Architekturen zu einem einzigen „Fat“-Bibliothek zusammenzuführen. Werkzeuge werden auch benötigt, um mehrere ABIs in das XCframework-Format zusammenzuführen, das Apple zur Verteilung mehrerer Frameworks für verschiedene ABIs in einem einzigen Bundle verwendet.

Ein Xcode-Projekt wird zur Ausführung der CPython-Testsuite bereitgestellt. Werkzeuge werden bereitgestellt, um den Prozess des Kompilierens des Testsuite-Binärprogramms, des Starts des Simulators, der Installation der Testsuite und ihrer Ausführung zu automatisieren.

Verteilung

Die Aufnahme von iOS als Tier-3-Plattform erfordert lediglich die Unterstützung für die Kompilierung eines iOS-kompatiblen Builds aus einem unveränderten CPython-Code-Checkout. Sie erfordert nicht die Erstellung offiziell verteilter iOS-Artefakte für Endbenutzer.

Wenn/wenn iOS auf Tier-2- oder Tier-1-Unterstützung aktualisiert wird, könnten die Werkzeuge zur Erstellung eines XCframework-Pakets zur Erstellung eines iOS-Verteilungsartefakts verwendet werden. Dieses könnte dann als „embedded distribution“ analog zur Windows-embedded-distribution oder als CocoaPod oder Swift-Paket verteilt werden, das zu einem Xcode-Projekt hinzugefügt werden könnte.

CI-Ressourcen

Anaconda hat angeboten, physische Hardware für die Ausführung von iOS-Buildbots bereitzustellen.

GitHub Actions kann iOS-Simulatoren auf seinen macOS-Maschinen hosten, und der iOS-Simulator kann durch Skripting-Umgebungen gesteuert werden. Die kostenlose Stufe bietet derzeit nur x86_64-macOS-Maschinen; jedoch sind ARM64-Runner kürzlich für kostenpflichtige Pläne verfügbar geworden. Um jedoch die macOS-Runner-Ressourcen nicht zu überlasten, wird kein GitHub Actions-Lauf für iOS als Teil der Standard-CI-Konfiguration hinzugefügt.

Packaging

iOS wird kein „universelles“ Wheel-Format bereitstellen. Stattdessen werden Wheels für jede ABI-Architektur-Kombination bereitgestellt.

iOS-Wheels werden Tags verwenden

• ios_12_0_arm64_iphoneos
• ios_12_0_arm64_iphonesimulator
• ios_12_0_x86_64_iphonesimulator

In diesen Tags ist „12.0“ die minimal unterstützte iOS-Version. Wie bei macOS wird der Tag die minimale iOS-Version enthalten, die bei der Kompilierung des Wheels ausgewählt wird; ein Wheel, das mit einer minimalen iOS-Version von 15.0 kompiliert wurde, würde die ios_15_0_*-Tags verwenden. Zum Zeitpunkt der Erstellung bietet iOS 12.0 die wichtigsten iOS-Funktionen und erreicht fast 100 % der Geräte; dies wird als Untergrenze für die iOS-Versionsübereinstimmung verwendet.

Diese Wheels können Binärmodule vor Ort enthalten (d. h. ko-lokal mit dem Python-Quellcode, genauso wie Wheels für eine Desktop-Plattform); sie müssen jedoch nachbearbeitet werden, da Binärmodule für die Verteilung in den „Frameworks“-Speicherort verschoben werden müssen. Dies kann mit einem Xcode-Build-Schritt automatisiert werden.

PEP 11 Update

PEP 11 wird aktualisiert, um zwei der iOS-ABIs aufzunehmen

• arm64-apple-ios
• arm64-apple-ios-simulator

Ned Deily wird der anfängliche Kernteam-Ansprechpartner für diese ABIs sein.

Das Ziel x86_64-apple-ios-simulator wird nach bestem Bemühen unterstützt, aber nicht als Tier-3-Ziel angestrebt. Dies liegt an der bevorstehenden Deprecation von x86_64 als Simulationsplattform, kombiniert mit der Schwierigkeit, x86_64 macOS-Hardware derzeit zu beauftragen.

Simulatorerkennung

Frühere Versionen dieser PEP schlugen die Aufnahme des Attributs sys.implementation._simulator vor, um zu identifizieren, wann Code auf einem Gerät oder auf einem Simulator läuft. Dies wurde aufgrund der Verwendung eines geschützten Namens für eine öffentliche API sowie der Verunreinigung des sys-Namespace mit einem iOS-spezifischen Detail abgelehnt.

Ein weiterer Vorschlag während der Diskussion war die Aufnahme einer generischen platform.is_emulator()-API, die von jeder Plattform implementiert werden könnte – beispielsweise um die Ausführung von x86_64-Code auf ARM64-Hardware zu unterscheiden oder wenn in QEMU oder anderen Virtualisierungsmethoden ausgeführt wird. Dies wurde mit der Begründung abgelehnt, dass nicht klar war, was eine konsistente Interpretation von „Emulator“ wäre oder wie ein Emulator außerhalb des iOS-Falls erkannt werden würde.

Die Entscheidung wurde getroffen, dieses Detail iOS-spezifisch zu halten und es in die platform.ios_ver()-API aufzunehmen.

GNU-Compiler-Triples

autoconf erfordert die Verwendung eines GNU-Compiler-Triples zur Identifizierung von Build- und Host-Plattformen. Die autoconf-Toolchain bietet jedoch keine native Unterstützung für iOS-Simulatoren, sodass wir uns mit der Frage auseinandersetzen müssen, wie iOS-Hardware in das Namensschema von GNU gezwängt werden kann.

Dies kann geschehen (mit einigen Patches von config.sub), führt aber zu 2 Hauptquellen für Namensinkonsistenzen

• arm64 vs aarch64 als Identifikator für 64-Bit-ARM-Hardware; und
• Welcher Identifikator für Simulatoren verwendet wird.

Apples eigene Tools verwenden arm64 als Architektur, scheinen aber in einigen Fällen tolerant gegenüber aarch64 zu sein. Die Geräteplattform wird als iphoneos und iphonesimulator identifiziert.

Rust-Toolchains verwenden aarch64 als Architektur und verwenden aarch64-apple-ios und aarch64-apple-ios-sim zur Identifizierung der Geräteplattform; sie verwenden jedoch x86_64-apple-ios, um iOS- *Simulatoren* auf x86_64-Hardware darzustellen.

Die Entscheidung fiel zugunsten von arm64-apple-ios und arm64-apple-ios-simulator, weil

1. Die autoconf-Toolchain bereits Unterstützung für ios als Plattform in config.sub enthält; nur der Simulator hat keine Darstellung.
2. Der dritte Teil des Host-Triples wird als sys.platform verwendet.
3. Wenn Apples eigene Tools die CPU-Architektur referenzieren, verwenden sie arm64, und die Verwendung der Architektur durch die GNU-Tools ist außerhalb des Build-Prozesses nicht sichtbar.
4. Wenn Apples eigene Tools den Simulatorstatus unabhängig vom Betriebssystem referenzieren (z. B. bei der Benennung von Swift-Submodulen), verwenden sie einen Suffix -simulator.
5. Während *einige* iOS-Pakete Rust verwenden werden, werden *alle* iOS-Pakete Apples Werkzeuge verwenden.

Die anfänglich angenommene Version dieses Dokuments verwendete die aarch64-Form als PEP 11-Identifikator; dies wurde während der Finalisierung korrigiert.

“Universelles” Wheel-Format

macOS unterstützt derzeit 2 CPU-Architekturen. Um die Benutzererfahrung zu verbessern, definiert Python ein „universal2“-Wheel-Format, das sowohl x86_64- als auch ARM64-Binärdateien enthält.

Es wäre konzeptionell möglich, ein analoges „universelles“ iOS-Wheel-Format anzubieten. Diese PEP verwendet diesen Ansatz jedoch aus 2 Gründen nicht.

Erstens hat sich die Erfahrung unter macOS, insbesondere im numerischen Python-Ökosystem, gezeigt, dass universelle Wheels äußerst schwierig zu handhaben sind. Während native macOS-Bibliotheken eine starke plattformübergreifende Unterstützung aufrechterhalten und Python selbst aktualisiert wurde, bietet die überwiegende Mehrheit der Upstream-Nicht-Python-Bibliotheken keine Multi-Architektur-Build-Unterstützung. Infolgedessen erfordert die Kompilierung universeller Wheels zwangsläufig mehrere Kompilierungsdurchläufe und komplexe Entscheidungen darüber, wie Header-Dateien für verschiedene Architekturen verteilt werden. Aufgrund dieser Komplexität bieten viele beliebte Projekte (einschließlich NumPy und Pillow) keine universellen Wheels an und stellen stattdessen separate ARM64- und x86_64-Wheels bereit.

Zweitens zeigt die historische Erfahrung, dass iOS eine flüssigere „universelle“ Definition erfordern würde. In den letzten 10 Jahren gab es *mindestens* 5 verschiedene Interpretationen von „universell“, die auf iOS zutreffen würden, darunter verschiedene Kombinationen von armv6, armv7, armv7s, arm64, x86 und x86_64 Architekturen, auf Geräten und Simulatoren. Wenn „Universal-iOS“ jetzt definiert würde, würde es wahrscheinlich x86_64 und arm64 auf Simulatoren sowie arm64 auf Geräten umfassen; die bevorstehende Deprecation von x86_64-Hardware würde jedoch eine weitere Interpretation hinzufügen; und es könnte in Zukunft notwendig werden, arm64e als neue Gerätearchitektur hinzuzufügen. Die Spezifizierung von iOS-Wheels als Single-Platform-Only bedeutet, dass das Python-Kernteam eine fortlaufende Standardisierungsdiskussion über die aktualisierten „universellen“ Formate vermeiden kann.

Es bedeutet auch, dass Wheel-Publisher individuelle Entscheidungen darüber treffen können, welche Plattformen unterstützt werden können. Ein Projekt kann sich beispielsweise entscheiden, die x86_64-Unterstützung einzustellen oder eine neue Architektur früher als andere Teile des Python-Ökosystems zu übernehmen. Die Verwendung von plattformspezifischen Wheels bedeutet, dass diese Entscheidung einzelnen Paketveröffentlichern überlassen werden kann.

Diese Entscheidung geht auf Kosten einer komplizierteren Bereitstellung. Die Bereitstellung unter iOS ist jedoch bereits ein komplizierter Prozess, der am besten durch Tools unterstützt wird. Derzeit ist keine Binärzusammenführung erforderlich, da es nur eine On-Device-Architektur gibt und Simulator-Binärdateien nicht als verteilbare Artefakte betrachtet werden, sodass nur eine Architektur zum Erstellen einer App für einen Simulator benötigt wird.

Unterstützung statischer Builds

Während die langfristige Machbarkeit der Option --undefined dynamic_lookup nicht garantiert ist, existiert die Option und funktioniert. Eine Option wäre, die Deprecation-Warnung zu ignorieren und zu hoffen, dass Apple entweder die Deprecation-Entscheidung rückgängig macht oder die Deprecation nie abschließt.

Da Apples Entscheidungsprozess völlig undurchsichtig ist, wäre dies im besten Fall eine riskante Option. In Kombination mit der Tatsache, dass das breitere iOS-Entwicklungsökosystem die Verwendung von Frameworks fördert, es keine Legacy-Verwendungen von statischen Bibliotheken gibt, die berücksichtigt werden müssen, und der einzige Vorteil einer statisch verknüpften iOS libpython3.x.a eine sehr geringfügig verkürzte App-Startzeit ist, erscheint das Weglassen der Unterstützung für statische Builds von libpython3.x als ein vernünftiger Kompromiss.

Es ist erwähnenswert, dass es einige Diskussionen über einen alternativen Ansatz zum Verknüpfen unter macOS gab, der die Notwendigkeit der Option --undefined dynamic_lookup beseitigen würde, obwohl die Diskussion über diesen Ansatz aufgrund von Implementierungskomplikationen ins Stocken geraten zu sein scheint. Wenn diese Komplikationen überwunden würden, ist es sehr wahrscheinlich, dass derselbe Ansatz unter iOS verwendet werden *könnte*, was eine statisch verknüpfte libpython3.x.a plausibel machen *würde*.

Die Entscheidung, Binärmodule gegen libpython3.x.dylib zu verknüpfen, würde die Einführung von statischen libpython3.x.a-Builds in Zukunft erschweren, da der Prozess der Umstellung auf einen anderen Ansatz zur Verknüpfung von Binärmodulen eine klare Möglichkeit erfordern würde, „dynamisch verknüpfte“ iOS-Binärmodule von „statisch kompatiblen“ iOS-Binärmodulen zu unterscheiden. Angesichts des Mangels an greifbaren Vorteilen einer statischen libpython3.x.a ist es jedoch unwahrscheinlich, dass eine solche Änderung erforderlich sein wird.

Interaktiver/REPL-Modus

Eine traditionelle python.exe-Kommandozeilen-Erfahrung ist auf Mobilgeräten nicht wirklich praktikabel, da Mobilgeräte keine Kommandozeile haben. iOS-Apps haben kein stdout, stderr oder stdin; und während stdout und stderr an das Systemprotokoll umgeleitet werden können, gibt es keine Quelle für stdin, die nicht auch die Erstellung einer sehr spezifischen benutzerorientierten App erfordert, die eher einer IDLE-ähnlichen IDE-Erfahrung ähneln würde. Daher wurde die Entscheidung getroffen, sich nur auf den „Embedded Mode“ als Ziel für die mobile Verteilung zu konzentrieren.

Unterstützung für x86_64-Simulatoren

Apple verkauft keine x86_64-Hardware mehr. Daher kann die Beauftragung eines x86_64-Buildbots schwierig sein. Es ist möglich, macOS-Binärdateien im x86_64-Kompatibilitätsmodus auf ARM64-Hardware auszuführen; dies ist jedoch für Testzwecke nicht ideal. Daher wird der x86_64-Simulator (x86_64-apple-ios-simulator) nicht als Tier-3-Ziel hinzugefügt. Es ist sehr wahrscheinlich, dass die iOS-Unterstützung ohne Änderungen auf x86_64 funktionieren wird; dies betrifft nur den *offiziellen* Tier-3-Status.

Tests auf Geräten

CI-Tests auf Simulatoren lassen sich relativ einfach unterbringen. Tests auf Geräten sind viel schwieriger, da die Verfügbarkeit von Gerätefarmen, die zur Bereitstellung von Buildbots oder Github Actions-Runnern konfiguriert werden könnten, begrenzt ist.

Tests auf Geräten sind jedoch möglicherweise nicht erforderlich. Als Datenpunkt – Apples Xcode Cloud-Lösung bietet keine Tests auf Geräten. Sie verlassen sich darauf, dass die API zwischen Gerät und Simulator konsistent ist und ARM64-Simulator-Tests ausreichen, um CPU-spezifische Probleme aufzudecken.

Reihenfolge der _multiarch-Tags

Die anfänglich akzeptierte Version dieses Dokuments verwendete die Reihenfolge <platform>-<arch> (z. B. iphoneos-arm64) für sys.implementation._multiarch (und verwandte Werte wie Wheel-Tags). Die endgültige zusammengeführte Version verwendet die Reihenfolge <arch>-<platform> (z. B. arm64-iphoneos). Dies geschieht zur Konsistenz mit Compiler-Triples auf anderen Plattformen (insbesondere Linux), die die Architektur vor dem Betriebssystem angeben.

Von platform.ios_ver() zurückgegebene Werte

Die anfänglich akzeptierte Version dieses Dokuments enthielt keine system-Kennung. Diese wurde während der Implementierungsphase hinzugefügt, um die Implementierung von platform.system() zu unterstützen.

Die anfänglich akzeptierte Version dieses Dokuments beschrieb auch, dass min_release im Ergebnis von ios_ver() zurückgegeben würde. Die endgültige Version lässt den Wert min_release weg, da er zur Laufzeit nicht signifikant ist; er beeinflusst nur die binäre Kompatibilität. Die Mindestversion *ist* im von sysconfig.get_platform() zurückgegebenen Wert enthalten, da dieser zur Definition der Kompatibilität von Wheels (und anderen Binärdateien) verwendet wird.