-
Notifications
You must be signed in to change notification settings - Fork 11
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
Build and publish Pyodide wheels #161
Build and publish Pyodide wheels #161
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One small thing
Additionally, I removed the |
Thanks. |
Description
This PR implements a few things across the workflow(s):
CIBW_
-prefixed environment variables for building Pyodide wheels. This requires a bump to thecibuildwheel
version, which has been updated to version 2.20.0, the latest available stable version. Support for building and publishing Pyodide wheels was introduced in version2.19.0
.cibuildwheel
from being pip-installed to its action as provided in the GitHub Actions marketplaceNote
I didn't run the test command for the Pyodide wheel step as of now, because of two reasons:
pow_dd
symbol when running the test suite (which I'll return in a while to investigate). If I am requested to enable the testing by the maintainers here, I can bring the alternative Node.js-based test runner file where the symbol visibility bug doesn't post a problem and use it to test the wheel here. Alternatively, the statsmodels submodule in this repository can be updated, and the file will appear. Please let me know if you would like me to do that.pytest-xdist
is not usable. Hence, testing the wheels takes much longer (~30 minutes). It will still be faster than the "ubuntu-latest, Python cp3X" jobs, however1.This is a follow-up PR after statsmodels/statsmodels#9270, which describes the rationale for this change. Please let me know if points two and three are better placed in a separate PR. Thank you!
Footnotes
Those jobs run for more than an hour, would it be alright if I parallelise them across the trio of manylinux-x86_64, musllinux-x86_64, and manylinux-aarch64? Doing this will lead to a 43% speedup – if yes, I could do so in a separate PR to keep the diff cleaner. ↩