Automatic wheels building for PyPI

[ggalloni]

This PR adds automatic building and publishing of wheels for Ubuntu and MacOS over the supported range of Python.

The reason for this PR is found in SOLikeT, where we depend on the PyPI version of pyccl, which, at this point, is dragging us down in terms of numpy (<2) and Python versions.

Of course, this PR also brings automatic updates on PyPI as a bonus feature.

The workflow to produce wheels took ~13 minutes and should hopefully cover the majority of needed builds.
If more are needed, they can eventually be added.

Off-topic: I've also added to the optional dependencies all the missing packages that were breaking (some) tests if not present.

EDIT: I've removed the extra dependencies just mentioned, as that is fixed in a better way by #1289.

[coveralls]

Coverage Report for CI Build 24400916357

Coverage remained the same at 97.469%

Details

• Coverage remained the same as the base build.
• Patch coverage: No coverable lines changed in this PR.
• No coverage regressions found.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

No coverage regressions found.

---

Coverage Stats

Relevant Lines:	6796
Covered Lines:	6624
Line Coverage:	97.47%
Coverage Strength:	4.87 hits per line

---

💛 - Coveralls

[carlosggarcia]

Thanks for the PR! I think it's a great addition.

I left some comments. In particular, before using the publish action in this PR, I'd like to test it in test.pypi to avoid issues like the one in #1284.

[carlosggarcia]

Can you add a block for test.pypi? Just to make sure the release doesn't break the official packages.

This was suggested by copilot.

  publish-testpypi:
    name: Publish to TestPyPI
    needs: [build_wheels, build_sdist]
    runs-on: ubuntu-latest
    if: github.event_name == 'workflow_dispatch'   # manual trigger only
    environment:
      name: testpypi
      url: https://test.pypi.org/p/pyccl
    permissions:
      contents: read
      id-token: write

    steps:
      - name: Download all artifacts
        uses: actions/download-artifact@v4
        with:
          pattern: cibw-*
          path: dist
          merge-multiple: true

      - name: Publish to TestPyPI
        uses: pypa/gh-action-pypi-publish@release/v1
        with:
          repository-url: https://test.pypi.org/legacy/

@damonge, @c-d-leonard I think we need your intervention to set up the identity provider in test-pypi https://test.pypi.org/project/pyccl/. Also, it might be good if you add desc-ccl as maintainer (which I believe is what we use to publish to pypi?).

[ggalloni]

Added, as you say, also in the next comments, I am assuming that trusted publishing is set up. So maybe some work is required by maintainers to fix that, if that is not true.

[carlosggarcia]

I believe this is not needed if we use the trusted connection https://docs.github.com/en/actions/how-tos/secure-your-work/security-harden-deployments/oidc-in-pypi.

[ggalloni]

Removed 👍

[carlosggarcia]

Here, copilot suggested to add an environment section. I am not familiar enough with pypi publishing to know if we should pay attention to it or not.

  environment:
    name: pypi
    url: https://pypi.org/p/pyccl

[ggalloni]

Yeah, that is required by trusted publishing, I've added that.

[carlosggarcia]

@ggalloni Thanks for the changes! I got access to the pypi and test.pypi and started working on setting up the trusted publisher. Doing so, I've discovered I have to set up the environment to publish, which I am not very sure how to do correctly right now. I've discovered this morning that the testpypi API credentials were already in GH (this TEST_PYPI_PYCCL_UPLOAD), so it might be faster if we use the old API credentials approach.

Would you mind reverting the trusted publisher set up and go back to using passwords? Sorry about the back and forth.

[ggalloni]

Hi @carlosggarcia, before reverting, let's give trusted publishing a try, as it should be much easier than anything else, and the standard procedure for PyPI publishing.

I did it yesterday for another repo, so the procedure is clearer to me too: on the side of pypi/testpypi, it is sufficient to specify the metadata of the repo and most importantly the name of the workflow used (publish.yml), and an environment name matching the one set by the workflow itself (pypi and testpypi, respectively). That's it, below I attach the screenshot for the testpypi case.

On the side of the repo, you just need to enter Settings > Environments and create said environments (pypi/testpypi). No need to set and manage secrets and such. Screenshot of the view on my repo below.