iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

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

This commit is contained in:
Russell Keith-Magee 2024-04-21 11:05:49 +08:00 committed by GitHub
parent 8d09efe2ba
commit 5feac329b9
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
2 changed files with 59 additions and 32 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
peps/pep-0011.rst
View File

@ -122,6 +122,8 @@ Tier 3
Target Triple Notes Contacts Target Triple Notes Contacts
================================ =========================== ======== ================================ =========================== ========
aarch64-pc-windows-msvc Steve Dower 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 armv7l-unknown-linux-gnueabihf Raspberry Pi OS, glibc, gcc Gregory P. Smith
powerpc64le-unknown-linux-gnu glibc, clang Victor Stinner powerpc64le-unknown-linux-gnu glibc, clang Victor Stinner

89
peps/pep-0730.rst
View File

@ -3,7 +3,7 @@ Title: Adding iOS as a supported platform
Author: Russell Keith-Magee <russell@keith-magee.com> Author: Russell Keith-Magee <russell@keith-magee.com>
Sponsor: Ned Deily <nad@python.org> Sponsor: Ned Deily <nad@python.org>
Discussions-To: https://discuss.python.org/t/pep730-adding-ios-as-a-supported-platform/35854 Discussions-To: https://discuss.python.org/t/pep730-adding-ios-as-a-supported-platform/35854
Status: Accepted Status: Final
Type: Standards Track Type: Standards Track
Content-Type: text/x-rst Content-Type: text/x-rst
Created: 09-Oct-2023 Created: 09-Oct-2023
@ -170,9 +170,9 @@ devices.
``sys.implementation._multiarch`` will describe the ABI and CPU architecture: ``sys.implementation._multiarch`` will describe the ABI and CPU architecture:
* ``"iphoneos-arm64"`` for ARM64 devices * ``"arm64-iphoneos"`` for ARM64 devices
* ``"iphonesimulator-arm64"`` for ARM64 simulators * ``"arm64-iphonesimulator"`` for ARM64 simulators
* ``"iphonesimulator-x86_64"`` for x86_64 simulators * ``"x86_64-iphonesimulator"`` for x86_64 simulators
``platform`` ``platform``
'''''''''''' ''''''''''''
@ -181,7 +181,8 @@ devices.
the values returned by the ``platform`` module will match those returned by the values returned by the ``platform`` module will match those returned by
``os.uname()``, with the exception of: ``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., * ``platform.release()`` - the iOS version number, as a string (e.g.,
``"16.6.1"``), instead of the Darwin kernel version. ``"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. ``platform.mac_ver()``, which can be used to provide macOS version information.
``ios_ver()`` will return a namedtuple that contains the following: ``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"``). * ``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., * ``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. * ``is_simulator`` - a boolean indicating if the device is a simulator.
``os`` ``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 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 ``sysconfigdata_name`` and Config makefile will follow the same patterns as
existing platforms (using ``sys.platform``, ``sys.implementation._multiarch`` existing platforms (using ``sys.platform``, ``sys.implementation._multiarch``
etc.) to construct identifiers. 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 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., 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 ``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 Compilation
----------- -----------
@ -302,16 +303,16 @@ provided for each ABI-arch combination.
iOS wheels will use tags: iOS wheels will use tags:
* ``ios_12_0_iphoneos_arm64`` * ``ios_12_0_arm64_iphoneos``
* ``ios_12_0_iphonesimulator_arm64`` * ``ios_12_0_arm64_iphonesimulator``
* ``ios_12_0_iphonesimulator_x86_64`` * ``ios_12_0_x86_64_iphonesimulator``
In these tags, "12.0" is the minimum supported iOS version. As with macOS, the 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 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 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_15_0_*`` tags. At time of writing, iOS 12.0 exposes most significant iOS
iOS features, while reaching near 100% of devices; this will be used as a floor features, while reaching near 100% of devices; this will be used as a floor for
for iOS version matching. iOS version matching.
These wheels can include binary modules in-situ (i.e., co-located with the 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 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 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`` * ``arm64-apple-ios``
* ``aarch64-apple-ios-simulator`` * ``arm64-apple-ios-simulator``
* ``x86_64-apple-ios-simulator``
Ned Deily will serve as the initial core team contact for these ABIs. 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 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 5. While *some* iOS packages will use Rust, *all* iOS packages will use Apple's
tooling. 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 "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 IDLE-style IDE experience. Therefore, the decision was made to only focus on
"embedded mode" as a target for mobile distribution. "embedded mode" as a target for mobile distribution.
Open Issues x86_64 simulator support
=========== ------------------------
x86_64 buildbot availability
----------------------------
Apple no longer sells x86_64 hardware. As a result, commissioning an x86_64 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 compatibility mode on ARM64 hardware; however, this isn't ideal for testing
purposes. 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
If native x86_64 Mac hardware cannot be sourced for buildbot purposes, it may be on the x86_64 without any modification; this only impacts on the *official* Tier
necessary to exclude the x86_64 simulator platform in Tier 3. Given the 3 status.
anticipated deprecation of x86_64 as a macOS development platform, this doesn't
pose a significant impediment to adoption or long term maintenance.
On-device testing 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 API is consistent between device and simulator, and ARM64 simulator testing is
sufficient to reveal CPU-specific issues. 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 Copyright
========= =========