[Python][Packaging] Set MACOSX_DEPLOYMENT_TARGET default before building wheel platform tag

[anxkhn]

Rationale for this change

In ci/scripts/python_wheel_macos_build.sh the wheel platform tag
_PYTHON_HOST_PLATFORM is built from MACOSX_DEPLOYMENT_TARGET one line before
that variable's :-12.0 default is applied. If 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>, even though the C++ libraries and the wheel are
actually built for 12.0. That produces an inconsistent, invalid platform tag on
the built wheel. The two export lines are simply in the wrong order.

What changes are included in this PR?

Swap the two adjacent export lines so the default is set first and the platform
tag is derived from the resolved value:

-export _PYTHON_HOST_PLATFORM="macosx-${MACOSX_DEPLOYMENT_TARGET}-${arch}"
 export MACOSX_DEPLOYMENT_TARGET=${MACOSX_DEPLOYMENT_TARGET:-12.0}
+export _PYTHON_HOST_PLATFORM="macosx-${MACOSX_DEPLOYMENT_TARGET}-${arch}"

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. No other lines are touched.

Are these changes tested?

There is no unit-test harness for these packaging shell scripts. I verified the
two lines in isolation:

• With the variable unset: before the change _PYTHON_HOST_PLATFORM=macosx--x86_64
  (malformed), after the change _PYTHON_HOST_PLATFORM=macosx-12.0-x86_64.
• With MACOSX_DEPLOYMENT_TARGET already set (for example 11.0): output is
  macosx-11.0-x86_64 both before and after, confirming no behavior change on the
  CI path.

shellcheck reports the same findings on this file before and after the change,
and bash -n passes. I did not run a full macOS wheel build (no Arrow C++
toolchain available in my environment); the existing packaging CI jobs exercise
the script end to end.

Are there any user-facing changes?

No API changes. The only observable difference is that a wheel produced by a
manual/local run of this script without MACOSX_DEPLOYMENT_TARGET exported now
gets a correct platform tag (macosx-12.0-<arch>) instead of a malformed one.
Wheels produced by the packaging CI are unaffected.

This PR contains a "Critical Fix". It fixes a bug that produced an invalid
platform tag (macosx--<arch>) on a built wheel when the script is run without
MACOSX_DEPLOYMENT_TARGET exported.

[github-actions]

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?

GH-${GITHUB_ISSUE_ID}: [${COMPONENT}] ${SUMMARY}

or

MINOR: [${COMPONENT}] ${SUMMARY}

See also:

• Other pull requests
• Contribution Guidelines - Contributing Overview

[Copilot]

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_PLATFORM so the platform tag is always derived from the resolved value.

[kou]

Could you open an issue for this.
See also: https://github.com/apache/arrow/blob/main/CONTRIBUTING.md#Minor-Fixes