Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 14 additions & 0 deletions tests/test_tags.py
Original file line number Diff line number Diff line change
Expand Up @@ -54,6 +54,7 @@ def get_abi3_suffix():

SUFFIX = sysconfig.get_config_var('EXT_SUFFIX')
ABI3SUFFIX = get_abi3_suffix()
STABLE_ABI_KIND = 'abi3t' if FREE_THREADED_BUILD and sys.version_info >= (3, 15) else 'abi3'


def test_wheel_tag():
Expand Down Expand Up @@ -162,3 +163,16 @@ def test_tag_mixed_abi():
}, pure=False, limited_api=True)
with pytest.raises(mesonpy.BuildError, match='The package declares compatibility with Python limited API but '):
assert str(builder.tag) == f'{INTERPRETER}-abi3-{PLATFORM}'


@pytest.mark.skipif(not ABI3SUFFIX, reason='interpreter does not support the stable ABI')
def test_tag_stable_abi_multiarch():
# Python 3.15 and later append the multiarch tuple to the stable ABI
# filename suffix. Verify that it is ignored rather than causing the
# module to be rejected: when cross compiling it differs from the one
# of the build interpreter.

@dnicolodi dnicolodi Aug 24, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had this kind of issue on my mind when thinking about the support for build-detail.json in #829. We have this check right now

abi3t = bool(sysconfig.get_config_var('Py_GIL_DISABLED')) and sys.version_info >= (3, 15)
expected_abi = 'abi3t' if abi3t else 'abi3'
which makes it impossible to cross-compile between a Python platform that uses abi3t and one that does not.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The regular expression used to extract the ABI from the filename matches both f'extension.{STABLE_ABI_KIND}-aarch64-linux-gnu.so' and f'extension.{STABLE_ABI_KIND}.so' and any other valid extension module filename, and this is verified at runtime. One test more is better than one test less, thus wer should include this one, but I would like to add some proper cross-compilation tests.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would like to add some proper cross-compilation tests.

💯 me too. However, that's for the build-details.json PR or a follow-up to that I think. This test is cheap (just regex/strings, no building), and would have caught an issue.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

which makes it impossible to cross-compile between a Python platform that uses abi3t and one that does not.

I think we can fix that up by extending support to more combinations once gh-829 is in? In practice there are lots of combinations of build/host-platform that are difficult. The most common one uses the same Python version and just changes the host platform. That's the test case I'd add first. Then extend from there.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test is cheap (just regex/strings, no building), and would have caught an issue.

Out of curiosity, which issue would this test have caught that other tests did have not?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can fix that up by extending support to more combinations once gh-829 is in?

Sure. It is just matter to replace checks against the values obtained from the current interpreter with checks against what is in build-details.json. Should we try to get gh-829 in for this release?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My review comment on gh-876: #876 (comment)

Which I think was a recurrence of the thing fixed in gh-322.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we try to get gh-829 in for this release?

Yes, that'd be great.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we try to get gh-829 in for this release?

Yes, that'd be great.

I can try to find time to finish the PR. However, I would be hesitant to merge it without an integration test. Ideally the test would compiler an extension module, thus it requires a C cross compiler and a build-details.json for the target foreign architecture. What's the easiest way to get these?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can also get the release out, merge it right after, and do another release. To take it off of the critical path (we shouldn't drop it for months though).

However, I would be hesitant to merge it without an integration test. Ideally the test would compiler an extension module, thus it requires a C cross compiler and a build-details.json for the target foreign architecture. What's the easiest way to get these?

Conda/pixi is the easiest way to get a cross compilation toolchain. I already have an integration test for scipy; would need to scope that down to running on a test package (or set of packages) and then adding it in a new CI job.

Let's move the CI coverage part to gh-829 though? I think we can discuss the release plan here; this PR is ready to go, and we can probably push to get 1-2 more PRs in, but then ship 0.21.0

builder = wheel_builder_test_factory({
'platlib': [f'extension.{STABLE_ABI_KIND}-aarch64-linux-gnu.so'],
}, pure=False, limited_api=True)
abi = 'abi3.abi3t' if STABLE_ABI_KIND == 'abi3t' else 'abi3'
assert str(builder.tag) == f'{INTERPRETER}-{abi}-{PLATFORM}'
2 changes: 1 addition & 1 deletion tests/test_wheel.py
Original file line number Diff line number Diff line change
Expand Up @@ -411,5 +411,5 @@ def test_limited_api_free_threaded(wheel_limited_api_free_threaded):
artifact = wheel.wheelfile.WheelFile(wheel_limited_api_free_threaded)
name = artifact.parsed_filename
assert name.group('pyver') == INTERPRETER
assert name.group('abi') == 'abi3.abi3t' if FREE_THREADED_BUILD else 'abi3'
assert name.group('abi') == ('abi3.abi3t' if FREE_THREADED_BUILD else 'abi3')

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ups! Thanks for catching this.

assert name.group('plat') == PLATFORM
Loading