diff --git a/peps/pep-0011.rst b/peps/pep-0011.rst index 62b98d382..f51a8562f 100644 --- a/peps/pep-0011.rst +++ b/peps/pep-0011.rst @@ -122,6 +122,8 @@ Tier 3 Target Triple Notes Contacts ================================ =========================== ======== aarch64-pc-windows-msvc Steve Dower +arm64-apple-ios iOS on device Ned Deily +arm64-apple-ios-simulator iOS on M1 macOS simulator Ned Deily armv7l-unknown-linux-gnueabihf Raspberry Pi OS, glibc, gcc Gregory P. Smith powerpc64le-unknown-linux-gnu glibc, clang Victor Stinner diff --git a/peps/pep-0730.rst b/peps/pep-0730.rst index 91ace1c37..0d997d873 100644 --- a/peps/pep-0730.rst +++ b/peps/pep-0730.rst @@ -3,7 +3,7 @@ Title: Adding iOS as a supported platform Author: Russell Keith-Magee Sponsor: Ned Deily Discussions-To: https://discuss.python.org/t/pep730-adding-ios-as-a-supported-platform/35854 -Status: Accepted +Status: Final Type: Standards Track Content-Type: text/x-rst Created: 09-Oct-2023 @@ -170,9 +170,9 @@ devices. ``sys.implementation._multiarch`` will describe the ABI and CPU architecture: -* ``"iphoneos-arm64"`` for ARM64 devices -* ``"iphonesimulator-arm64"`` for ARM64 simulators -* ``"iphonesimulator-x86_64"`` for x86_64 simulators +* ``"arm64-iphoneos"`` for ARM64 devices +* ``"arm64-iphonesimulator"`` for ARM64 simulators +* ``"x86_64-iphonesimulator"`` for x86_64 simulators ``platform`` '''''''''''' @@ -181,7 +181,8 @@ devices. the values returned by the ``platform`` module will match those returned by ``os.uname()``, with the exception of: -* ``platform.system()`` - ``"iOS"``, instead of the default ``"Darwin"`` +* ``platform.system()`` - ``"iOS"`` or ``iPadOS`` (depending on the hardware in + use), instead of ``"Darwin"`` * ``platform.release()`` - the iOS version number, as a string (e.g., ``"16.6.1"``), instead of the Darwin kernel version. @@ -190,11 +191,11 @@ In addition, a ``platform.ios_ver()`` method will be added. This mirrors ``platform.mac_ver()``, which can be used to provide macOS version information. ``ios_ver()`` will return a namedtuple that contains the following: +* ``system`` - the OS name (``iOS`` or ``iPadOS``, depending on hardware) * ``release`` - the iOS version, as a string (e.g., ``"16.6.1"``). -* ``min_release`` - the minimum supported iOS version, as a string (e.g., - ``"12.0"``) * ``model`` - the model identifier of the device, as a string (e.g., - ``"iPhone13,2"``). On simulators, this will return ``"iPhoneSimulator"``. + ``"iPhone13,2"``). On simulators, this will return ``"iPhone"`` or ``"iPad"``, + depending on the simulator device. * ``is_simulator`` - a boolean indicating if the device is a simulator. ``os`` @@ -214,7 +215,7 @@ This approach treats the ``os`` module as a "raw" interface to system APIs, and ''''''''''''' The ``sysconfig`` module will use the minimum iOS version as part of -``sysconfig.get_platform()`` (e.g., ``"ios-12.0-iphoneos-arm64"``). The +``sysconfig.get_platform()`` (e.g., ``"ios-12.0-arm64-iphoneos"``). The ``sysconfigdata_name`` and Config makefile will follow the same patterns as existing platforms (using ``sys.platform``, ``sys.implementation._multiarch`` etc.) to construct identifiers. @@ -238,7 +239,7 @@ into a Framework location. This finder will only be installed if ``sys.platform This finder will convert a Python module name (e.g., ``foo.bar._whiz``) into a unique Framework name by using the full module name as the framework name (i.e., ``foo.bar._whiz.framework``). A framework is a directory; the finder will look -for ``_whiz.dylib`` in that directory. +for a binary named ``foo.bar._whiz`` in that directory. Compilation ----------- @@ -302,16 +303,16 @@ provided for each ABI-arch combination. iOS wheels will use tags: -* ``ios_12_0_iphoneos_arm64`` -* ``ios_12_0_iphonesimulator_arm64`` -* ``ios_12_0_iphonesimulator_x86_64`` +* ``ios_12_0_arm64_iphoneos`` +* ``ios_12_0_arm64_iphonesimulator`` +* ``ios_12_0_x86_64_iphonesimulator`` In these tags, "12.0" is the minimum supported iOS version. As with macOS, the tag will incorporate the minimum iOS version that is selected when the wheel is compiled; a wheel compiled with a minimum iOS version of 15.0 would use the -``ios_15_0_iphone*`` tags. At time of writing, iOS 12.0 exposes most significant -iOS features, while reaching near 100% of devices; this will be used as a floor -for iOS version matching. +``ios_15_0_*`` tags. At time of writing, iOS 12.0 exposes most significant iOS +features, while reaching near 100% of devices; this will be used as a floor for +iOS version matching. These wheels can include binary modules in-situ (i.e., co-located with the Python source, in the same way as wheels for a desktop platform); however, they @@ -322,14 +323,18 @@ build step. PEP 11 Update ------------- -:pep:`11` will be updated to include the three iOS ABIs: +:pep:`11` will be updated to include two of the iOS ABIs: -* ``aarch64-apple-ios`` -* ``aarch64-apple-ios-simulator`` -* ``x86_64-apple-ios-simulator`` +* ``arm64-apple-ios`` +* ``arm64-apple-ios-simulator`` Ned Deily will serve as the initial core team contact for these ABIs. +The ``x86_64-apple-ios-simulator`` target will be supported on a best-effort +basis, but will not be targeted for tier 3 support. This is due to the impending +deprecation of x86_64 as a simulation platform, combined with the difficulty of +commissioning x86_64 macOS hardware at this time. + Backwards Compatibility ======================= @@ -436,6 +441,8 @@ The decision was made to use ``arm64-apple-ios`` and 5. While *some* iOS packages will use Rust, *all* iOS packages will use Apple's tooling. +The initially accepted version of this document used the ``aarch64`` form as the PEP 11 identifier; this was corrected during finalization. + "Universal" wheel format ------------------------ @@ -523,21 +530,16 @@ involve building a very specific user-facing app that would be closer to an IDLE-style IDE experience. Therefore, the decision was made to only focus on "embedded mode" as a target for mobile distribution. -Open Issues -=========== - -x86_64 buildbot availability ----------------------------- +x86_64 simulator support +------------------------ Apple no longer sells x86_64 hardware. As a result, commissioning an x86_64 -buildbot may not be possible. It is possible to run macOS binaries in x86_64 +buildbot can be difficult. It is possible to run macOS binaries in x86_64 compatibility mode on ARM64 hardware; however, this isn't ideal for testing -purposes. - -If native x86_64 Mac hardware cannot be sourced for buildbot purposes, it may be -necessary to exclude the x86_64 simulator platform in Tier 3. Given the -anticipated deprecation of x86_64 as a macOS development platform, this doesn't -pose a significant impediment to adoption or long term maintenance. +purposes. Therefore, the x86_64 Simulator (``x86_64-apple-ios-simulator``) will +not be added as a Tier 3 target. It is highly likely that iOS support will work +on the x86_64 without any modification; this only impacts on the *official* Tier +3 status. On-device testing ----------------- @@ -551,6 +553,29 @@ Cloud solution doesn't provide on-device testing. They rely on the fact that the API is consistent between device and simulator, and ARM64 simulator testing is sufficient to reveal CPU-specific issues. +Ordering of ``_multiarch`` tags +------------------------------- + +The initially accepted version of this document used ``-`` +ordering (e.g., ``iphoneos-arm64``) for ``sys.implementation._multiarch`` (and +related values, such as wheel tags). The final merged version uses the +``-`` ordering (e.g., ``arm64-iphoneos``). This is for +consistency with compiler triples on other platforms (especially Linux), which +specify the architecture before the operating system. + +Values returned by ``platform.ios_ver()`` +----------------------------------------- + +The initially accepted version of this document didn't include a ``system`` +identifier. This was added during the implementation phase to support the implementation of ``platform.system()``. + +The initially accepted version of this document also described that +``min_release`` would be returned in the ``ios_ver()`` result. The final version +omits the ``min_release`` value, as it is not significant at runtime; it only +impacts on binary compatibility. The minimum version *is* included in the value +returned by ``sysconfig.get_platform()``, as this is used to define wheel (and +other binary) compatibility. + Copyright =========