Just my 2 cents about building universal2 wheels. From past experience with intel wheels, It might not always be a great idea.

From a packager point of view (so, here, user of cibuildwheel):

While the build might seem easy for simple enough packages, I guess it might get a bit more complicated for packages requiring to build other native dependencies, especially if those do not support universal2 builds out of the box, requiring some (well known ?) tricks to combine 2 builds in an universal2 build.
"Yeah, my build and tests are ok with cibuildwheel, let's publish on PyPI"
Well, we shall remember that those wheels are never tested with the arm64 kicking in (at least for now and until Apple Silicon is available in CI, e.g. Support for VMs on Apple M1 actions/runner-images#2187). This means some testing must be done manually. In Run 32-bit tests on macOS #202, we could see that some wheels were able to build/test with the intel tag but were not being able to just be imported on i686 which implies that cibuildwheel (and probably other tools as mentioned in Run 32-bit tests on macOS #202) was not doing its job properly (IMHO).

From an end-user point of view (I'm a Mac end-user if that matters):

Because of point 2 on the packager side, I expect reports that package some-package just doesn't work.
"Do I really need universal2 ?"
The simple answer to this question is probably "no, you just need what matches your hardware"
"Why is downloading wheels slower ? / Why did disk usage grow so much ?"
A simple sample will illustrate. It's basic and flawed but gives the gist of things.

Matt$ python3.8 -m venv cp38
Matt$ source cp38/bin/activate
Matt$ pip install scikit-learn scikit-image
Matt$ du -hs ./cp38/lib/python3.8/site-packages
349M	./cp38/lib/python3.8/site-packages
Matt$ find ./cp38/lib/python3.8/site-packages -type f -a \( -name '*.so' -o -name '*.dylib' \) | xargs du -ch | sort -h
...
...
202M	total

This means if wheels are all packaged as universal2 wheels, the new install would be roughly 551 MB, that's almost a 60% increase.

To sum-up, am I against universal2 wheels ? no, it might make sense for projects like websockets (real small C extension part of a bigger project), simpler for packager, does not change much package size for end-user. That being said, I think there must be an option to target x86_64, arm64 or universal2 (and maybe build universal2 then split it in two wheels).
This will not help with testing arm64/universal2 for now which shall be clearly documented to avoid any misunderstanding that running a test step in cibuildwheel will cover these cases.

Reading material that might be of interest:
https://conda-forge.org/blog/posts/2020-10-29-macos-arm64/

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions