Build Python ABI3 wheels instead of a wheel per Python version
Closes #891
I would rather merge for 0.15 after some extensive testing.
Most notably, we also remove our hard-coded splits for less common architectures to avoid having to upload multiple crates
Pull Request Test Coverage Report for Build 8649595792
Details
- 0 of 0 changed or added relevant lines in 0 files are covered.
- No unchanged relevant lines lost coverage.
- Overall coverage increased (+0.03%) to 96.528%
| Totals | |
|---|---|
| Change from base Build 8639249844: | 0.03% |
| Covered Lines: | 17320 |
| Relevant Lines: | 17943 |
💛 - Coveralls
I still need to remove ~~the ppc64 musl build that also failed the 0.14 release and~~ the test file... apart from that it should be fine
@mtreinish this should be ready to review, all the wheels build in https://github.com/IvanIsCoding/rustworkx/actions/runs/8400723506
LGTM, and thanks for manually validating the builds. I just had 2 quick inline questions but not a blocker per say.
The other question I had was did you do any performance testing to see if there was a measurable impact from moving to abi3?
I did not benchmark it, maybe we should run https://github.com/mtreinish/retworkx-comparison-benchmarks against the main branch vs this PR. Unfortunately the performance won't get better, but maybe it will not get that much worse?
Let's go ahead and merge it now. We can benchmark it after it merges pretty easily. At least when we made this change with qiskit it wasn't really measurable and we can offset it potentially by leveraging PGO or something. But even if there is a small performance regression, the portability benefits are worth it.
@BastianZim @wshanks FYI I don’t know how this affects https://github.com/conda-forge/rustworkx-feedstock but for 0.15.x we will be distributing less binaries. I hope it simplifies your work in conda too
Thanks, @IvanIsCoding. Distributing less binaries doesn't help us directly because we build from source any way, but I hope we can make use of the fact that RustworkX is abi3 compatible in the future. Currently, changes to conda are needed because conda doesn't know where site-packages is outside of a Python version-specific path (like lib/python3.10/site-packages). There is a special noarch format that can do it but here we need something arch-specific but not Python specific. It has been discussed in https://github.com/conda-forge/conda-forge.github.io/issues/1865. I also made a test with the Qiskit package in https://github.com/conda-forge/qiskit-terra-feedstock/pull/41 where I found that conda seemed to hard-code the version range of the Python dependency as well when building a package with Python. I did find that abi3 builds of Qiskit worked for me across Python versions using a symlink to fake the site-packages location and forcing conda to ignore the Python version during install. Hopefully conda gets better support some day :slightly_smiling_face: