Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FR: support dynamic CIBW_PRERELEASE_PYTHON and CIBW_FREETHREADED_SUPPORT in publish.yml #212

Closed
neutrinoceros opened this issue Jun 23, 2024 · 2 comments

Comments

@neutrinoceros
Copy link
Contributor

Rationale:
cibuildwheel itself allows the following combination of env vars

CIBW_BUILD="cp312-* cp313-*"
CIBW_PRERELEASE_PYTHONS="false"

which results in only cp312 wheels being built (since CPython 3.13 is at pre-release stage)
However, if I use OpenAstronomy/github-actions-workflows/.github/workflows/publish.yml@v1, I need to specify targets explicitly as, for instance:

targets: |
  - cp312-manylinux_x86_64
  - cp313-manylinux_x86_64
  - ...

which, if I also set CIBW_PRERELEASE_PYTHONS="false", results in the following error

cibuildwheel: No build identifiers selected: BuildSelector(build_config='cp313-manylinux_x86_64', skip_config='', requires_python=<SpecifierSet('>=3.10')>, prerelease_pythons=False, free_threaded_support=False)

This is important in case we want to set CIBW_PRERELEASE_PYTHONS dynamically, as for instance in astropy/astropy#16596

A possible workaround is to use wildcards when specifying targets, e.g.,

targets: |
  - cp312-*
  - cp313-*

but then jobs take much longer in wall time since you lose parallelism.

It seems possible to support this use case by updating target discovery so it's aware of these env vars (CIBW_PRERELEASE_PYTHON and CIBW_FREETHREADED_SUPPORT) and can dynamically skip any matching wheels as needed. However I see one difficulty to discuss/overcome
The list of versions to be ignored if CIBW_PRERELEASE_PYTHON!="true" depends on cibuildwheel's version (and indirectly on calendar), so supporting this would also require keeping the list in sync with cibuildwheel. To minimize impact of potential errors, we could choose to keep the current behavior in case CIBW_PRERELEASE_PYTHON isn't defined at all.

I'm happy to contribute a patch if this is desirable, once the matter is discussed.

Conversation originated at astropy/astropy#16596 (comment)

@ConorMacBride
Copy link
Member

The easiest solution would be to pass the --allow-empty argument to cibuildwheel to prevent the error, however that's not possible with their GitHub Action. I've opened pypa/cibuildwheel#1922 to see if a CIBW_ALLOW_EMPTY env var could be added, and then you could also set that when you set CIBW_PRERELEASE_PYTHONS="true".

@neutrinoceros
Copy link
Contributor Author

@ConorMacBride Your patch was just released as part of https://github.com/pypa/cibuildwheel/releases/tag/v2.20.0, so I think this can be closed now. Thank you !

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

No branches or pull requests

2 participants