Add workflow for building wheels and publishing releases to PyPI

[matt-graham]

Should resolve #214

Adds a GitHub Actions workflow with a job using cibuildwheel to build binary wheels across multiple differing platforms and a second job building a sdist (source distribution), for each push to main, on pull-requests and published releases, uploading the built wheels as artefacts. For published releases specifically, a third job will upload the built wheels and sdist to Test PyPI and then if that is successful upload to the main PyPI repository.

This workflow is adapted from the example at

https://github.com/pypa/cibuildwheel/blob/3d3159b37bcd2c183583b67136b5f5de757e8232/examples/github-deploy.yml

and associated tutorial. For the publishing to PyPI job to work, we will need to configure trusted publishing to allow GitHub Actions to publish to the s2fft PyPI project - this will need to be set up by @CosmoMatt as it looks like you are the current maintainer of project on PyPI.

[matt-graham]

Marking this as draft for now as looks like building on at least some of current platforms being targetted will be problematic.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 93.28%. Comparing base (543dfca) to head (837b0e4).
Report is 41 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #235   +/-   ##
=======================================
  Coverage   93.28%   93.28%           
=======================================
  Files          29       29           
  Lines        3170     3170           
=======================================
  Hits         2957     2957           
  Misses        213      213           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[matt-graham]

The builds on ubuntu-latest and macos-14 (running on arm64) seem to both be completing fine for all Python versions, but we're getting errors consistently when trying to build on macos-13 (running on x86_64 architecture)

Error output when building on MacOS x86_64

  Building wheels for collected packages: s2fft
    Building wheel for s2fft (pyproject.toml): started
    Building wheel for s2fft (pyproject.toml): finished with status 'error'
    error: subprocess-exited-with-error
    
    × Building wheel for s2fft (pyproject.toml) did not run successfully.
    │ exit code: 1
    ╰─> [39 lines of output]
        /private/var/folders/73/klh957sj02nd7k78vl8ckkcm0000gn/T/pip-build-env-lw0x25zn/overlay/lib/python3.9/site-packages/setuptools_scm/git.py:167: UserWarning: "/Users/runner/work/s2fft/s2fft" is shallow and may cause errors
          warnings.warn(f'"{wd.path}" is shallow and may cause errors')
        *** scikit-build-core 0.10.7 using CMake 3.30.4 (wheel)
        *** Configuring CMake...
        loading initial cache file build/cp39-cp39-macosx_10_9_x86_64/CMakeInit.txt
        -- The CXX compiler identification is AppleClang 15.0.0.15000100
        -- Detecting CXX compiler ABI info
        -- Detecting CXX compiler ABI info - done
        -- Check for working CXX compiler: /Applications/Xcode_15.2.app/Contents/Developer/usr/bin/g++ - skipped
        -- Detecting CXX compile features
        -- Detecting CXX compile features - done
        -- Using CMake version: 3.30.4
        -- Looking for a CUDA compiler
        -- Looking for a CUDA compiler - NOTFOUND
        CMake Warning at CMakeLists.txt:61 (message):
          CUDA compiler not found, building without CUDA support
        
        
        -- Found Python: /private/var/folders/73/klh957sj02nd7k78vl8ckkcm0000gn/T/cibw-run-01_1zwjn/cp39-macosx_x86_64/build/venv/bin/python (found suitable version "3.9.13", minimum required is "3.8") found components: Interpreter Development.Module
        -- Configuring done (8.8s)
        -- Generating done (0.0s)
        -- Build files have been written to: /Users/runner/work/s2fft/s2fft/build/cp39-cp39-macosx_10_9_x86_64
        *** Building project with Ninja...
        [1/13] Building CXX object CMakeFiles/nanobind-static.dir/private/var/folders/73/klh957sj02nd7k78vl8ckkcm0000gn/T/pip-build-env-lw0x25zn/overlay/lib/python3.9/site-packages/nanobind/src/nb_type.cpp.o
        FAILED: CMakeFiles/nanobind-static.dir/private/var/folders/73/klh957sj02nd7k78vl8ckkcm0000gn/T/pip-build-env-lw0x25zn/overlay/lib/python3.9/site-packages/nanobind/src/nb_type.cpp.o
        /Applications/Xcode_15.2.app/Contents/Developer/usr/bin/g++ -DNB_COMPACT_ASSERTIONS -I/private/var/folders/73/klh957sj02nd7k78vl8ckkcm0000gn/T/pip-build-env-lw0x25zn/overlay/lib/python3.9/site-packages/nanobind/ext/robin_map/include -I/Library/Frameworks/Python.framework/Versions/3.9/include/python3.9 -I/private/var/folders/73/klh957sj02nd7k78vl8ckkcm0000gn/T/pip-build-env-lw0x25zn/overlay/lib/python3.9/site-packages/nanobind/include -O3 -DNDEBUG -std=gnu++17 -arch x86_64 -isysroot /Applications/Xcode_15.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.2.sdk -mmacosx-version-min=10.9 -fPIC -fvisibility=hidden -fno-strict-aliasing -MD -MT CMakeFiles/nanobind-static.dir/private/var/folders/73/klh957sj02nd7k78vl8ckkcm0000gn/T/pip-build-env-lw0x25zn/overlay/lib/python3.9/site-packages/nanobind/src/nb_type.cpp.o -MF CMakeFiles/nanobind-static.dir/private/var/folders/73/klh957sj02nd7k78vl8ckkcm0000gn/T/pip-build-env-lw0x25zn/overlay/lib/python3.9/site-packages/nanobind/src/nb_type.cp
        /private/var/folders/73/klh957sj02nd7k78vl8ckkcm0000gn/T/pip-build-env-lw0x25zn/overlay/lib/python3.9/site-packages/nanobind/src/nb_type.cpp:248:13: error: aligned deallocation function of type 'void (void *, std::align_val_t) noexcept' is only available on macOS 10.13 or newer
                    operator delete(p, std::align_val_t(t->align));
                    ^
        /private/var/folders/73/klh957sj02nd7k78vl8ckkcm0000gn/T/pip-build-env-lw0x25zn/overlay/lib/python3.9/site-packages/nanobind/src/nb_type.cpp:248:13: note: if you supply your own aligned allocation functions, use -faligned-allocation to silence this diagnostic
        1 error generated.
        [2/13] Building CXX object CMakeFiles/_s2fft.dir/lib/src/extensions.cc.o
        [3/13] Building CXX object CMakeFiles/nanobind-static.dir/private/var/folders/73/klh957sj02nd7k78vl8ckkcm0000gn/T/pip-build-env-lw0x25zn/overlay/lib/python3.9/site-packages/nanobind/src/nb_ndarray.cpp.o
        [4/13] Building CXX object CMakeFiles/nanobind-static.dir/private/var/folders/73/klh957sj02nd7k78vl8ckkcm0000gn/T/pip-build-env-lw0x25zn/overlay/lib/python3.9/site-packages/nanobind/src/nb_internals.cpp.o
        [5/13] Building CXX object CMakeFiles/nanobind-static.dir/private/var/folders/73/klh957sj02nd7k78vl8ckkcm0000gn/T/pip-build-env-lw0x25zn/overlay/lib/python3.9/site-packages/nanobind/src/nb_func.cpp.o
        [6/13] Building CXX object CMakeFiles/nanobind-static.dir/private/var/folders/73/klh957sj02nd7k78vl8ckkcm0000gn/T/pip-build-env-lw0x25zn/overlay/lib/python3.9/site-packages/nanobind/src/nb_enum.cpp.o
        ninja: build stopped: subcommand failed.
        
        *** CMake build failed
        [end of output]
    
    note: This error originates from a subprocess, and is likely not a problem with pip.
    ERROR: Failed building wheel for s2fft
  Failed to build s2fft
  ERROR: Failed to build one or more wheels

Looks to be some compatibility issue with nanobind source files rather than anything specifically in s2fft and from a bit of searching I can't find any obvious solutions. For now I've just removed macos-13 from build matrix.

[CosmoMatt]

@matt-graham awesome stuff, I can add you as a maintainer to s2fft on Pypi if that would simplify things? Regardless you should have maintainer permissions, do you have a PyPi account?

Might want to hold off on this whilst we wrap up the current core infrastructure work. When we next aim to make a release we should do so through merging this PR, how does that sound?

[matt-graham]

@matt-graham awesome stuff, I can add you as a maintainer to s2fft on Pypi if that would simplify things? Regardless you should have maintainer permissions, do you have a PyPi account?

If you're happy to add me as a maintainer on PyPI then yep that would probably simplify things as I can set up the trusted publishing myself then - my PyPI account is https://pypi.org/user/MattGraham/. If it's okay to also add me as with admin permissions on this repository then I can also do the configuration required on the GitHub side (setting up environments with appropriate protection rules at https://github.com/astro-informatics/s2fft/settings/environments) or alternatively can leave those steps to you (should be fairly simple).

Might want to hold off on this whilst we wrap up the current core infrastructure work. When we next aim to make a release we should do so through merging this PR, how does that sound?

That sounds reasonable.

[CosmoMatt]

@matt-graham Definitely happy to add you, you're one of the original contributors on the code and therefore should have had these privileges regardless! You should have a maintainer invitation to s2fft on PyPi and should now have admin access to the repository.

[matt-graham]

Just to note, a new pypi GitHub environment has now been added and trusted publishing set up on PyPI.

[CosmoMatt]

@matt-graham great stuff, will this also increment the version number of the code or is this something we'll need to do manually?

[matt-graham]

setuptools_scm which we added in the previous pyproject.toml PR should already deal with setting version automatically from the latest release tag 🙂. So for example if we create a release with a tag v1.2.0 the package version in the project metadata / on PyPI / accessible as an attribute of the package will automatically be derived from that release tag.