ENH: implement support for build-details.json (PEP 739) (continued) by mgorny · Pull Request #829 · mesonbuild/meson-python

mgorny · 2026-01-08T15:42:07Z

This a continuation of #779. For a start, I just did a dumb rebase to rerun the tests.

rgommers · 2026-06-28T09:11:50Z

I closed gh-779. Copying over the main comment from that PR discussion:

Good point. Yes, there isn't any reason that build-details.json cannot be used for a native build. So we should support that as well. That said, there isn't a benefit from the user passing in such a file explicitly; we can start reading it automatically for Python >=3.14, but I'm a bit hesitant to do that right away since it's so new. We can start doing that at any point in the future if it helps simplify our internal code, since it's a backwards-compatible change.

So for now in this PR we can distinguish three cases, with the user passing:

Only a cross file (or multiple cross files)
Only a build-details.json file
Both a cross file and a build-details.json file

I focused on (3) first and have a TODO in here already to add (1); I should add (2) as well.

dnicolodi

I had a quick look at this. Found some possible improvements.

dnicolodi · 2026-06-29T07:28:27Z

-            return mesonpy._tags.Tag('py3', 'none', None)
-        return mesonpy._tags.Tag(None, self._stable_abi, None)
+            return mesonpy._tags.Tag('py3', 'none', None, self._build_details)
+        return mesonpy._tags.Tag(None, self._stable_abi, None, self._build_details)


I think a mesonpy._tags.Tag.from_build_details() API would work better. This would avoid to have to pass the build details object to a bunch of functions that do close to nothing when the Python interpreter description is available from build-details.json.

BTW: build-details.json is really a ugly name.

I don't understand this point. The JSON file does not provide a "ready" wheel tag, and we still need all of the "postprocessing" these functions do.

I have been looking at this a bit more, and I still don't like how we need to handle the case where build_details are available vs when we need to introspect the interpreter. One practical thing, is that it is not clear at a first glance that all the information used in deriving the tag really comes from build_details and not from the current platform. Mixing the two is obviously wrong.

Therefore, I propose to turn this around: have a mesonpy._tags.BuildDetails dictionary populated with introspection data when the required info does not come from a build-details.json file, pass that around, and remove all conditional handling.

Working on that. Also, uh, I just discovered a direct mesonpy._tags.get_abi_tag() in build_editable() that didn't account for build-details.json. I suppose it's not really critical since it only determines the build directory, but still.

I just discovered a direct mesonpy._tags.get_abi_tag() in build_editable() that didn't account for build-details.json. I suppose it's not really critical since it only determines the build directory, but still.

cross-built editable wheels are not a thing: they wheel is installed in the same environment where the build is running without ever been exposed as a build artifact. Thus that does not need to be changed.

Okay, done that. I've split the macosx/ios logic into two functions: one that performs tasks specific to getting current platform, and another that performs postprocessing using the data from BuildDetails (which may be the current platform or build-details.json). This also implies that passing BuildDetails to the functions is required.

I have left build_editable()'s build-dir use current system, given that implementing build-details.json support there would involve quite a bit of duplication, and it doesn't seem a major issue to solve anyway.

mgorny · 2026-07-02T18:50:30Z

I'm going to rebase it now, and make changes later when I find more time.

mgorny · 2026-07-03T15:36:19Z

Updated and rebased now.

dnicolodi · 2026-07-05T19:48:13Z

I tied up some loose ends. I think this is ready to be merged now. @rgommers, do you want to take a look?

It would be nice to have an integration test for this, but I don't know how hard it is to get a suitable environment setup on GitHub Actions.

mgorny · 2026-07-06T03:58:34Z

Actually, I think it was in Draft because we wanted to make an integration test, but we were blocked on build-details.json problems in conda packages. I need to recheck if we resolved them all now.

rgommers · 2026-07-06T05:19:39Z

Sounds great! Indeed, that integration test would be nice. IIRC conda-forge/python-feedstock#858 should have solved the one issue in conda-forge that was blocking for a cross-compile test.

thesamesam

This looks reasonable to me but I don't touch the meson-python side of things often at all.

dnicolodi · 2026-08-24T15:41:55Z

+        # passing the with the `-Dpython.build_config=` option to `meson
+        # setup`. Extract the value passed to this option and use the details
+        # in the `build-details.json` file to compute the wheel tag.
+        self._build_details: mesonpy._tags.BuildDetails | None = None


This annotation is now wrong: self._build_details cannot be None. Also, now that we use this attribute to always store information on the interpreter we can consider to name it in a less confusing way (now, at a first look it could seem that this attribute contains information about the build of the Meson project). Maybe self._info is not too bad of a name.

It is None temporarily. Unless you want me to undo the optimization and set the default value unconditionally, then override if python_build_config arg is provided.

I don't mind renaming it, though info sounds a bit unclear. Maybe tag_info? Should I also rename the classes and the argument elsewhere?

dnicolodi · 2026-08-24T15:46:38Z

+    # Python built with older macOS SDK on macOS 11, reports an
+    # nonexistent macOS 10.16 version instead of the real version.
+    #
+    # The packaging module introduced a workaround
+    # https://github.com/pypa/packaging/commit/67c4a2820c549070bbfc4bfbf5e2a250075048da
+    #
+    # This results in packaging versions up to 21.3 generating
+    # platform tags like "macosx_10_16_x86_64" and later versions
+    # generating "macosx_11_0_x86_64".  Using the latter would be more
+    # correct but prevents the resulting wheel from being installed on
+    # systems using packaging 21.3 or earlier (pip 22.3 or earlier).
+    #
+    # Fortunately packaging versions carrying the workaround still
+    # accepts "macosx_10_16_x86_64" as a compatible platform tag.  We
+    # can therefore ignore the issue and generate the slightly
+    # incorrect tag.


What about the code this comments refers to?

My understanding is that this comment is saying that we don't need any code to handle that case. It was followed by empty line, then another comment. I've figured out it's better to move it where we get the platform, since it applied to what the system gives us.

dnicolodi · 2026-08-24T16:08:15Z

+        pass

-    return f'ios_{version[0]}_{version[1]}_{multiarch}'
+    return f'{platform_os}_{version.replace('.', '_')}_{multiarch.replace('-', '_')}'


Also, why join the version with . to replace it with _ here? Overall, I liked how this was written before much more, among other things because it was symmetric to what is done for macos.

I've written it under the assumption that we should have the same input whether it's taken from the platform or from build-details.json. Since the latter uses dots, I've used the same here. Ofc, it practically doesn't matter, so I can go with underscores, but the conversion will still be necessary for build-details.json.

mgorny · 2026-08-24T16:23:28Z

When I'm done addressing feedback, I'm going to add more tests for the tag logic.

Signed-off-by: Michał Górny <mgorny@quansight.com>

mgorny changed the title ~~WIP: ENH: implement support for build-details.json (PEP 739)~~ WIP: ENH: implement support for build-details.json (PEP 739) (continued) Jan 8, 2026

mgorny mentioned this pull request Jan 8, 2026

CI: Various fixes to make CI green #830

Closed

mgorny force-pushed the pep-739-cross branch from c3d8702 to 9862d32 Compare January 9, 2026 16:36

lucascolley mentioned this pull request May 26, 2026

BLD: Allow to set python path also via meson scipy/scipy#18167

Draft

rgommers mentioned this pull request Jun 28, 2026

WIP: ENH: implement support for build-details.json (PEP 739) and cross compilation #779

Closed

rgommers added the enhancement New feature or request label Jun 28, 2026

dnicolodi requested changes Jun 29, 2026

View reviewed changes

mgorny force-pushed the pep-739-cross branch 2 times, most recently from f22d77f to 7758d1c Compare July 3, 2026 15:36

dnicolodi requested changes Jul 4, 2026

View reviewed changes

Comment thread mesonpy/__init__.py Outdated

Comment thread tests/test_tags.py Outdated

Comment thread tests/test_tags.py Outdated

Comment thread mesonpy/__init__.py Outdated

Comment thread mesonpy/__init__.py Outdated

dnicolodi force-pushed the pep-739-cross branch from 1d80550 to 9cb0c4a Compare July 5, 2026 17:13

dnicolodi marked this pull request as ready for review July 5, 2026 17:14

dnicolodi changed the title ~~WIP: ENH: implement support for build-details.json (PEP 739) (continued)~~ ENH: implement support for build-details.json (PEP 739) (continued) Jul 5, 2026

dnicolodi force-pushed the pep-739-cross branch 3 times, most recently from 3e48d47 to bba067e Compare July 5, 2026 17:38

dnicolodi force-pushed the pep-739-cross branch from bba067e to 2bb7038 Compare July 5, 2026 20:20

dnicolodi force-pushed the pep-739-cross branch 3 times, most recently from 3fe11bd to 5ced90e Compare July 6, 2026 12:31

dnicolodi requested changes Jul 6, 2026

View reviewed changes

Comment thread mesonpy/_tags.py Outdated

thesamesam reviewed Aug 6, 2026

View reviewed changes

dnicolodi mentioned this pull request Aug 24, 2026

TST: fix a small abi3t tag test issue, and add a new test for multiarch filename #882

Open

mgorny force-pushed the pep-739-cross branch from 6b9e33e to 0c8510d Compare August 24, 2026 14:34

ENH: implement support for build-details.json (PEP 739)

08a6811

mgorny force-pushed the pep-739-cross branch 3 times, most recently from 2b989fd to aee6205 Compare August 24, 2026 15:41

dnicolodi requested changes Aug 24, 2026

View reviewed changes

mgorny force-pushed the pep-739-cross branch from aee6205 to 9a15dc2 Compare August 24, 2026 16:11

mgorny force-pushed the pep-739-cross branch from 530d443 to 7f88a9f Compare August 24, 2026 16:42

Use BuildDetails for the native build case as well

ce79e07

Signed-off-by: Michał Górny <mgorny@quansight.com>

mgorny force-pushed the pep-739-cross branch from 7f88a9f to ce79e07 Compare August 24, 2026 16:47

Uh oh!

Conversation

mgorny commented Jan 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rgommers commented Jun 28, 2026

Uh oh!

dnicolodi left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

mgorny commented Jul 2, 2026

Uh oh!

mgorny commented Jul 3, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

dnicolodi commented Jul 5, 2026

Uh oh!

mgorny commented Jul 6, 2026

Uh oh!

rgommers commented Jul 6, 2026

Uh oh!

Uh oh!

thesamesam left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mgorny commented Aug 24, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

mgorny commented Jan 8, 2026 •

edited

Loading