gh-122931: Allow stable abi3 API extensions to include a multiarch tuple in the filename#152461
gh-122931: Allow stable abi3 API extensions to include a multiarch tuple in the filename#152461stefanor wants to merge 14 commits into
Conversation
…ple in the filename This permits stable ABI extensions for multiple architectures to be co-installed into the same directory, without clashing with each other, the same way (non-stable ABI) regular extensions can. It is listed below the current .abi3 suffix because setuptools will select the first suffix containing .abi3, as the target filename. We do this to protect older Python versions predating this patch.
…uple in the filename This permits `abi3` stable ABI extensions for multiple architectures to be co-installed into the same directory, without clashing with each other, the same way (non-stable ABI) regular extensions can. It is listed before the current .abi3 suffix because .abi3 extensions are only compatible with future Python releases, not older versions. This follows on from python#122917 which was reduced down to just targetting `abi3t`
Documentation build overview
121 files changed ·
|
|
The SC agreed to add the arch-specific abi3t I'll update & merge this PR. |
Add ALT_SOABI and SOABI_PLATFORM to test.pythoninfo. Add also EXTENSION_SUFFIXES of importlib.machinery.
|
This was previously a commit following on from #122917. There has been some movement in there since this was filed. Cherry-picked those commits for here. |
|
This change adds the following strings to
On Free Threading, it adds the following string to
For example, no new string is added on these platforms:
On the PR gh-122917, @stefanor wrote that the change only impacts Linux. But it does impact other platforms: Emscripten, macOS and WASI for example. Is it expected/useful to use these new suffixes on Emscripten/WASI? For example, use On macOS, we support Intel and AArch64 architectures but The cryptography uses the stable ABI. On PyPI, I can only see download files for ARM64 on macOS: https://pypi.org/project/cryptography/#files. |
So, I primarily care about Linux here, that's where the pain is. And that's probably the platform where working with multiple architectures is the most common. To me the addition makes sense and is potentially useful on all of those platforms (FreeBSD and Windows too). But figuring out the details for this all would probably take some time. We could restrict it to Linux only to get this merged now. Fat binaries are common on macOS, but you'd only build one at a time, and combine them into a fat binary. |
Maybe we're overthinking this. These platforms already have the additional |
Currently, we don't support the "platform triplet" on FreeBSD (same on OpenBSD or NetBSD). The But on FreeBSD, Maybe we should explore the The commit d3899c1 of issue gh-67169 in 2015 introduced Result of
|
|
Since the point of the feature is to have different
|
|
🤖 New build scheduled with the buildbot fleet by @encukou for commit 0ebab06 🤖 Results will be shown at: https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F152461%2Fmerge If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again. |
|
test_curses fails on RHEL8 buildbot workers, but these workers should only be run on Python 3.12 and older. Example: https://github.com/python/buildmaster-config/blob/519dfd6b9757ab889d32677b71c074c5ccc2096c/master/custom/workers.py#L115. |
This permits
abi3stable ABI extensions for multiple architectures to be co-installed into the same directory, without clashing with each other, the same way (non-stable ABI) regular extensions can.It is listed before the current
.abi3suffix because .abi3 extensions are only compatible with future Python releases, not older versions.This follows on from #122917 which was reduced down to just targetting
abi3t