Open ankith26 opened 1 week ago
While doing this PR I also happened to
Here is a table of cumulated-time comparisons, along with per config notes
Platform | Before (main) | After (this PR) | Extra Notes |
---|---|---|---|
Windows x86_64 | 37m 33s (3m 37s, 3m 10s, 3m 52s, 4m 23s, 4m 13s, 4m 30s, 4m 50s, 8m 58s) | 15m 19s | Numpy tests removed on pypy 3.10 |
Windows x86 | 19m 22s (4m 16s, 3m 5s, 4m 6s, 4m 45s, 3m 10s) | 9m 10s | - |
macOS arm64 | 15m 0s (10m 23s, 4m 37s) | 10m 15s | Added 3 new pypy runs |
macOS x86_64 | 27m 7s (7m 49s, 8m 30s, 10m 48s) | 15m 8s | Numpy tests removed on pypy 3.10 |
Linux arm64 | 13m 43s | 11m 48s | Added numpy for tests where possible |
Linux x86_64 | 11m 43s | 10m 44s | Added numpy for tests where possible |
Linux x86 | 12m 58s | 11m 1s | - |
The goal of this PR is to centralize all common cibuildwheel config, and make our CI more uniform.
We currently take different strategies on different workflows. manylinux takes the "build for all pythons in one workflow per arch" strategy. Mac takes an (ever so slightly harder to maintain) strategy of handwritten "split jobs evenly" while windows takes the "every run on its own" thing. I figured that the strategy manylinux takes is actually the most efficient, even if it's slower than the rest. Why?
pyproject.toml
Also switches build backend to
build[uv]
which should again save some CI time.I may also explore more in the caching area in future PRs and see how that improves things.