Skip to content

CI: Use Cython nightly wheel on free-threaded CI #20942

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

Merged
merged 3 commits into from
Jun 12, 2024

Conversation

andfoy
Copy link
Contributor

@andfoy andfoy commented Jun 11, 2024

Reference issue

See #20669

What does this implement/fix?

Since Cython nightly wheels are now being published in the Scientific Python Anaconda channel, SciPy free-threaded CIs now can use them as opposed to building them in-place, this will reduce overall execution times.

Additional information

See scientific-python/upload-nightly-action#80

@andfoy andfoy requested review from larsoner and andyfaff as code owners June 11, 2024 16:52
@andfoy andfoy changed the title CI: Use Cython nightly whwheel on free-threaded CI CI: Use Cython nightly wheel on free-threaded CI Jun 11, 2024
@github-actions github-actions bot added the CI Items related to the CI tools such as CircleCI, GitHub Actions or Azure label Jun 11, 2024
@andfoy andfoy requested a review from rgommers as a code owner June 11, 2024 16:54
run: |
pip install git+https://github.com/cython/cython
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could also just add NO_CYTHON_COMPILE=true to the start of these lines to accomplish the same thing, if the only objective is to reduce CI time, as noted in the linked discussion.

I don't think the distinction matters much, depends on how closely you want to match the frequency of changes/breaks in Cython source vs. less frequently updated wheels.

Since both free-threaded CI jobs I'm aware of (the wheel one and regular one) both look fine here, it is probably just fine to merge this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, the upside of compiling Cython in-place is that issues such as #20717 (comment) could be caught earlier, however, I don't know if the frequency of source changes in Cython is something that SciPy wants to keep track after 3.13 comes up and Cython wheels can be installed directly from PyPi

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

compiling Cython in-place

That issue was specific to a compiled version of Cython? I'm just saying that the new wheels you propose to use here are not compiled Cython IIUC, just the raw Python source (which is mostly fine), and the purpose of the PR to

reduce overall execution times

could be accomplished by either pulling in the non-compiled wheels or by pulling in the raw source from GitHub and specifying to pip not to compile it, and the only difference is the frequency of change. Maybe using the wheels is less likely to pick up noise.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think regressions are happing often. I like the idea of using Cython nightly wheels. The trade-off is that fixes in Cython master may take a little longer to materialize. But so far we haven't had any problems in the free-threaded build with Cython, so I think choosing faster install times and a bit more stability makes sense.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

choosing faster install times

Ok, I don't think this one is true if you disable the compile on the pip install, but I think we agree on the rest.

@tylerjereddy tylerjereddy added this to the 1.15.0 milestone Jun 11, 2024
@rgommers rgommers added the free-threading Items related to supporting free-threaded (a.k.a. "no-GIL") builds of CPython label Jun 11, 2024
Copy link
Member

@rgommers rgommers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @andfoy. This mostly looks good to me, however you forget to update cibw_before_build_linux.sh - could you make the same change there?

Copy link
Member

@rgommers rgommers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @andfoy, let's give this a go. And thanks for the review @tylerjereddy.

@rgommers rgommers merged commit cf8e87d into scipy:main Jun 12, 2024
@rgommers
Copy link
Member

As a next step here, now that CPython 1.13.0b2 is out and NumPy has free-threaded macOS wheels, I think you could try adding macOS nightly wheels for SciPy as well?

@andfoy andfoy deleted the use_free_threaded_cython branch June 12, 2024 13:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CI Items related to the CI tools such as CircleCI, GitHub Actions or Azure free-threading Items related to supporting free-threaded (a.k.a. "no-GIL") builds of CPython
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants