Finalize PEP 730, and add iOS to PEP 11 (#3761)

Author: freakboy3742

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
 

peps/pep-0730.rst

@@ -3,7 +3,7 @@ Title: Adding iOS as a supported platform
 Author: Russell Keith-Magee <[email protected]>
 Sponsor: Ned Deily <[email protected]>
 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 ``<platform>-<arch>``
+ordering (e.g., ``iphoneos-arm64``) for ``sys.implementation._multiarch`` (and
+related values, such as wheel tags). The final merged version uses the
+``<arch>-<platform>`` 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
 =========