Minimum supported macOS version

[liammegill]

🐛 Bug Report

Recent cf-units macOS wheels have required a progressively newer macOS:

• 3.2.0: macosx_11_0 (arm64)
• 3.3.0: macosx_14_0 (arm64)
• 3.3.1: macosx_15_0

On any Mac older than the floor, pip install cf-units finds no compatible wheel and silently falls back to building from the sdist, which fails outright (see the traceback below), because it seems to require NDUNITS2_XML_PATH. For v3.3.1, this is a hard failure for pip-only users not on macOS 15 (conda installations work fine - from what I can tell because the conda-installed ndunits2 provides NDUNITS2_XML_PATH).

The root cause looks to be in .github/workflows/ci-wheels.yml (bumped from macOS 14.0 to 15.0 in #621):

MACOSX_DEPLOYMENT_TARGET=$([[ ${{ matrix.os }} == 'macos-latest' ]] && echo '26.0' || echo '15.0')

I am of course not intimitely familiar with the cf-units codebase, but my naive suggested fix would be simply to pin MACOSX_DEPLOYMENT_TARGET to a fixed, conservative value (e.g. 12.0, 13.0 - whatever minimum the codebase needs). Or is there something blocking this?

How to Reproduce

Steps to reproduce the behaviour, on a Mac running an OS older than the latest wheel's floor (in my specific case, macOS 14.x trying to install v3.3.1):

1. python3 -m venv env && source env/bin/activate
2. pip install cf-units
3. pip finds no compatible wheel, falls back to the sdist and the build fails with ValueError: Require to set UDUNITS2_XML_PATH for a cf-units wheel build.

On my machine, pip install "cf-units!=3.3.1" (resolving to 3.3.0) works, because the floor of that version was macOS 14.0.

Expected Behaviour

pip install cf-units should find and install a compatible wheel on any reasonably recent macOS (e.g. within Apple's N-2 support window).

Environment

• OS & Version: macOS 14.7.6 (Sonoma, currently still within N-2 support window)
• cf-units Version: 3.3.1

Additional Context

Click to expand this section...

$ python3 -m venv env && source env/bin/activate
$ pip install cf-units
Collecting cf-units
  Using cached cf_units-3.3.1.tar.gz (311 kB)
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
  Preparing metadata (pyproject.toml) ... done
Building wheels for collected packages: cf-units
  Building wheel for cf-units (pyproject.toml) ... error
  error: subprocess-exited-with-error

  × Building wheel for cf-units (pyproject.toml) did not run successfully.
  │ exit code: 1
  ╰─> [23 lines of output]
      ...
      File "<string>", line 168, in <module>
      File "<string>", line 82, in get_package_data
      ValueError: Require to set UDUNITS2_XML_PATH for a cf-units wheel build.
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.
  ERROR: Failed building wheel for cf-units
error: failed-wheel-build-for-install

× Failed to build installable wheels for some pyproject.toml based projects
╰─> cf-units

Available wheel tags per release, from PyPI:

3.2.0: cf_units-3.2.0-cp3{8,9,10,11}-...-macosx_10_9_x86_64.whl
       cf_units-3.2.0-cp3{8,9,10,11}-...-macosx_11_0_arm64.whl
3.3.0: cf_units-3.3.0-cp3{10,11,12,13}-...-macosx_13_0_x86_64.whl
       cf_units-3.3.0-cp3{10,11,12,13}-...-macosx_14_0_arm64.whl
3.3.1: cf_units-3.3.1-cp311-abi3-macosx_15_0_arm64.whl
       cf_units-3.3.1-cp311-abi3-macosx_15_0_x86_64.whl

Thanks very much!

[trexfeathers]

I am of course not intimitely familiar with the cf-units codebase, but my naive suggested fix would be simply to pin MACOSX_DEPLOYMENT_TARGET to a fixed, conservative value (e.g. 12.0, 13.0 - whatever minimum the codebase needs). Or is there something blocking this?

I don't know, sorry. None of the core maintainers work with MacOS unfortunately. We try to add support for different builds when outside experts can suggest the right way to do so. We specifically have trouble with availability of GitHub Actions runners, and GitHub's own deprecation cycle (which is presumably independent of the N-2 support window).

If you are able to propose a pull request, we can take a look, but we do not have the in-house expertise ourselves.

[pp-mo]

We try to add support for different builds when outside experts can suggest the right way to do so ...
we do not have the in-house expertise ourselves.

Very well put - sad but true.

[liammegill]

Thanks for the response! That's totally understandable. I didn't realise that GitHub Actions runners are now only available for 15.0 onwards... I will see whether I can figure out whether there are any blockers for releasing new versions for older macOS versions and can open a PR if I get anywhere. Thanks!