Skip to content

Fix macOS platform tag detection for conda interpreters (#14267)#18416

Closed
edschofield wants to merge 1 commit intoastral-sh:mainfrom
PythonCharmers:fix/macos-conda-platform-tags
Closed

Fix macOS platform tag detection for conda interpreters (#14267)#18416
edschofield wants to merge 1 commit intoastral-sh:mainfrom
PythonCharmers:fix/macos-conda-platform-tags

Conversation

@edschofield
Copy link
Copy Markdown
Contributor

@edschofield edschofield commented Mar 12, 2026

This PR fixes issue #14267 on Intel Macs with conda Python builds.

Details

On Intel Macs running macOS 11+, conda's Python is built with MACOSX_DEPLOYMENT_TARGET=10.15. When platform.mac_ver() is called, Apple's SYSTEM_VERSION_COMPAT shim returns "10.16" instead of the real OS version. This causes uv to generate macosx-10.16 platform tags, missing packages that only publish wheels for macOS 11.0+ (e.g. pyarrow, greenlet, duckdb, tabmat).

This patch detects the fake "10.16" version and re-query with SYSTEM_VERSION_COMPAT=0 to get the real macOS version. It uses the exact same approach as the packaging library used by pip (see here).

With this patch, uv pip install pyarrow greenlet duckdb tabmat correctly installs all four binary wheels in a minimal conda environment my Intel iMac (2020) running macOS 14.8.3 instead of trying (and failing) to build the packages from source.

On Intel Macs running macOS 11+, conda's Python is built with
MACOSX_DEPLOYMENT_TARGET=10.15. When platform.mac_ver() is called,
Apple's SYSTEM_VERSION_COMPAT shim returns "10.16" instead of the
real OS version. This causes uv to generate macosx-10.16 platform
tags, missing packages that only publish wheels for macOS 11.0+
(e.g. pyarrow, greenlet, duckdb, tabmat).

Detect the fake "10.16" version and re-query with
SYSTEM_VERSION_COMPAT=0 to get the real macOS version. This matches
the behavior of the `packaging` library used by pip.

Fixes astral-sh#14267
@notatallshaw
Copy link
Copy Markdown
Collaborator

It uses the exact same approach as the packaging library used by pip (see here).

As a packaging (and pip maintainer), looking forward to one day deleting that code.

try:
import subprocess

real_version = subprocess.run(
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 just be setting SYSTEM_VERSION_COMPAT=0 when running this process in the first place instead of running a second process?

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.

(From some brief research it seems like we should)

Copy link
Copy Markdown
Contributor Author

@edschofield edschofield Mar 13, 2026

Choose a reason for hiding this comment

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

I think you're right. Your approach works in my testing. I'll close this PR and make another one.

@edschofield
Copy link
Copy Markdown
Contributor Author

Superseded by this patch: #18436

zanieb added a commit that referenced this pull request Mar 14, 2026
…18452)

Closes #14267
Replaces #18436 — adding my review
because I cannot push there
Replaces #18416

---------

Co-authored-by: Ed Schofield <ed@pythoncharmers.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants