The cibuildwheel documentation has a note about this (https://cibuildwheel.readthedocs.io/en/stable/faq/#universal2), quoting:
> The dual-architecture universal2 has a few benefits, but a key benefit to > a universal wheel is that a user can bundle these wheels into an application > and ship a single binary. > > However, if you have a large library, then you might prefer to ship the two > single-arch wheels instead - x86_64 and arm64. In rare cases, you might want > to build all three, but in that case, pip will not download the universal > wheels, > because it prefers the most specific wheel available. So given that we are in the situation of having a large library, and already do provide the separate x86_64 and arm64 wheels (and thus pip will actually never use the universal2 wheel by default), I think it seems fine to drop the universal2 wheels. Joris On Thu, 27 Oct 2022 at 10:05, Antoine Pitrou <anto...@python.org> wrote: > > > Hello, > > Currently, for macOS we're publishing both arm64, x86_64 *and* > universal2 binary wheels (the latter contain both arm64 and x86_64 code > in a single binary). > > Here are some observations from me: > > * Producing universal2 wheels is more complex than producing > single-architecture wheels (we actually have to build for both > architectures separately, then merge the results); it's also one more > CI/packaging configuration to look after > > * x86-64 Macs are legacy and are gradually disappearing (especially for > high-performance applications where ARM Macs are massively faster) > > * Numpy publishes only architecture-specific wheels, while Pandas > publishes both architecture-specific and universal wheels > > * Size-wise, a universal wheel is not much smaller than the sum of > architecture-specific wheels (for example, 43.7 MB for > pyarrow-9.0.0-cp310-cp310, vs. 24.0 MB + 21.6 MB) > > Is there any reason why we should continue publishing universal wheels > for macOS? > > Regards > > Antoine.
