build Python wheels with cibuildwheel and add to build workflow

[zacharyburnett]

closes #389, blocked by #390 [fixed]

[zacharyburnett]

The current blocking issue with building is that repairwheel can't find the C extension in the built wheel. Perhaps it is not included for some reason, maybe an issue with the setuptools config:

Repairing wheel...

    + sh -c 'auditwheel repair -w /tmp/cibuildwheel/repaired_wheel /tmp/cibuildwheel/built_wheel/s2geometry-0.0.0-cp37-cp37m-linux_x86_64.whl'
INFO:auditwheel.main_repair:Repairing s2geometry-0.0.0-cp37-cp37m-linux_x86_64.whl
INFO:auditwheel.main_repair:This does not look like a platform wheel, no ELF executable or shared library file (including compiled Python C extension) found in the wheel archive

[zacharyburnett]

I'm not sure exactly what to put here; this just modifies the example from https://scikit-build.readthedocs.io/en/latest/usage.html#basic-usage

[zacharyburnett]

unfortunately, using scikit-build still fails to provide the s2geometry module:

Run source .venv/bin/activate && python -c "import s2geometry"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
    import s2geometry
ModuleNotFoundError: No module named 's2geometry'

[zacharyburnett]

building the Python 3.8 wheels for macos-latest and macos-15-intel fails with the following error:
https://github.com/google/s2geometry/actions/runs/24573839604/job/71853883913#step:3:612

error: aligned allocation function of type 'void *(std::size_t, std::align_val_t)' is only available on macOS 10.13 or newer
error: aligned deallocation function of type 'void (void *, std::align_val_t) noexcept' is only available on macOS 10.13 or newer

[jmr]

error: aligned allocation function of type 'void *(std::size_t, std::align_val_t)' is only available on macOS 10.13 or newer

Since the error is in absl, this is an absl bug, although I think other places in S2 will have this problem.

https://github.com/abseil/abseil-cpp#support

Support for 10.13 will be dropped in the summer, so I wouldn't worry too much about this one.

https://github.com/google/oss-policies-info/blob/main/foundational-cxx-support-matrix.md#macos

Why is this only a problem for this PR?

We can add

set(CMAKE_OSX_DEPLOYMENT_TARGET "10.13" CACHE STRING "Minimum macOS version")

before project().

[zacharyburnett]

Progress! the repair wheel step now fails on macOS with

delocate.libsana.DelocationError: Failed to find any binary with the required architecture: 'arm64'

delocate.libsana.DelocationError: Failed to find any binary with the required architecture: 'x86_64'

[zacharyburnett]

It looks like skipping wheel delocation for macOS lets cibuildwheel proceed, and the import tests pass with the built wheel; I'll test the uploaded artifacts on my arm64 machine when the workflow finishes

[zacharyburnett]

testing these wheels locally on macOS ARM, the tests at src/python/*_test.py that imported s2geometry passed, but the ones that tried to import s2geometry_pybind failed (I assume because those need Bazel in order to be included in the wheel?). I think this PR is ready to merge for the SWIG bindings.

In order to publish to PyPI, @figroc just needs to configure the PyPI project https://pypi.org/project/s2geometry/ to add this repository (https://github.com/google/s2geometry) and build workflow (build.yml) to the list of Trusted Publishers. Then, on the next github release, the wheels will automatically upload to PyPI with the tagged version

[zacharyburnett]

I don't know if C++ SWIG can make use of the "Limited API / Stable ABI" (https://docs.cython.org/en/latest/src/userguide/limited_api.html) but if so, that would make it so that only a single wheel would have to be built and published, instead of having to build a wheel for each Python version. But that would probably require changes in src/python/ that are out of scope of this PR

[figroc]

Done

In order to publish to PyPI, @figroc just needs to configure the PyPI project https://pypi.org/project/s2geometry/ to add this repository (https://github.com/google/s2geometry) and build workflow (build.yml) to the list of Trusted Publishers.

[jmr]

Hmm. This seems like it could run us into problems with multiple absl verisons.

What shared libs do you end up with?

[jmr]

I need to learn more about these permissions. What's the alternative to putting this in a workflow?

[zacharyburnett]

this is to use Trusted Publishers with PyPI, see here: https://docs.github.com/en/actions/how-tos/secure-your-work/security-harden-deployments/oidc-in-pypi

from what I understand, after authenticating via OIDC, the workflow exchanges the token for a single-use PyPI publish token that it then uses to upload the wheels

[jmr]

I don't know if C++ SWIG can make use of the "Limited API / Stable ABI" (https://docs.cython.org/en/latest/src/userguide/limited_api.html)

Yes, it does. I'll see about adding this separately.

https://www.swig.org/Doc4.2/Python.html#Python_stable_abi

https://cmake.org/cmake/help/latest/module/FindPython.html#:~:text=Python%20embedding%20developments.-,Added%20in%20version%203.26%3A,-Development.SABIModule%3A%20search

[jmr]

Yes, it does. I'll see about adding this separately.

Added in 0b302d5

[zacharyburnett]

minor change: project.optional-dependencies are more for "features" visible to the user (they could do pip install s2geometry[test]); using dependency-groups denotes this as dependency for devs instead (install with pip install --group test)