GH-50531: [Python][Packaging] Set macOS deployment target before building wheel platform tag#50377
GH-50531: [Python][Packaging] Set macOS deployment target before building wheel platform tag#50377anxkhn wants to merge 1 commit into
Conversation
|
Thanks for opening a pull request! If this is not a minor PR. Could you open an issue for this pull request on GitHub? https://github.com/apache/arrow/issues/new/choose Opening GitHub issues ahead of time contributes to the Openness of the Apache Arrow project. Then could you also rename the pull request title in the following format? or See also: |
There was a problem hiding this comment.
Pull request overview
Fixes a macOS wheel packaging issue where _PYTHON_HOST_PLATFORM could be derived from an unset MACOSX_DEPLOYMENT_TARGET, producing a malformed wheel platform tag during manual/local builds.
Changes:
- Set
MACOSX_DEPLOYMENT_TARGET(with its default) before exporting_PYTHON_HOST_PLATFORMso the platform tag is always derived from the resolved value.
|
Could you open an issue for this. |
anxkhn
changed the title
|
Opened #50531 as requested and updated this PR title and description to link it and follow the contribution format. Thank you for pointing me to the minor-fix policy. |
|
|
…ing wheel platform tag In ci/scripts/python_wheel_macos_build.sh the wheel platform tag _PYTHON_HOST_PLATFORM was assembled from MACOSX_DEPLOYMENT_TARGET one line before that variable's :-12.0 default was applied. When the script runs without MACOSX_DEPLOYMENT_TARGET already exported (for example a manual or local macOS build), the interpolation yields a malformed tag with an empty version component (macosx--<arch>), while the C++ libraries and the wheel are actually built for 12.0. That produces an inconsistent, invalid platform tag on the built wheel. Swap the two lines so the default is set first and the platform tag is derived from the resolved value. When MACOSX_DEPLOYMENT_TARGET is already set (as in the packaging CI, which exports it as a top-level env var), the output is unchanged, so there is no behavior change for existing jobs. Verified the two lines in isolation with the variable unset: before the change _PYTHON_HOST_PLATFORM=macosx--x86_64, after the change macosx-12.0-x86_64. The full macOS wheel build was not run (no Arrow C++ toolchain available locally).
fe42499 to
a3b3ef1
Compare
Rationale for this change
ci/scripts/python_wheel_macos_build.shbuilds_PYTHON_HOST_PLATFORMfromMACOSX_DEPLOYMENT_TARGETbefore applying its default. If the script is run without that variable exported, it produces a malformedmacosx--<arch>tag even though the build then targets macOS 12.0.Closes #50531.
What changes are included in this PR?
Apply the
MACOSX_DEPLOYMENT_TARGETdefault before deriving_PYTHON_HOST_PLATFORM. Existing CI invocations that already set the deployment target are unchanged.Are these changes tested?
bash -npasses. I also checked the relevant assignments with the variable unset and explicitly set: the unset case now producesmacosx-12.0-x86_64, while an explicit target remains unchanged. A full wheel build was not run.Are there any user-facing changes?
No API changes. Manual or local wheel builds that rely on the default now receive a valid platform tag.
This change was made with help from an AI coding assistant. I reviewed and verified the one-line ordering fix.