Drop linux i686 from auto archs for v3.0 ?

[joerick]

(I am sorry for not thinking to discuss this sooner!)

I realised we have a situation in v3.0 where manylinux images are split - most archs are by default on manylinux_2_28, but i686 is still on manylinux2014. This is unlikely to remedy itself in the future - i686 is legacy at this point, with even Microsoft dropping support for it in Windows 11.

Should we remove i686 from the auto keyword on x86_64 machines?

I think @henryiii suggested something similar a few weeks back. I'm curious if @mayeut has an opinion on this.

[mayeut]

I'd rather not change this now.
Debian is still supporting i686 & there are more than 20% of active manylinux packages still producing i686 wheels.
Changing the default behavior of auto will not break for the vast majority of users but will likely break something in those 20% packages.
If we are considering i686 to be a thing of the past (on any OS), then I'd probably go with a new enable flag to disable by default but not change the meaning of auto arch.

[joerick]

That's cool. I'd be curious how much use those i686 packages are getting, maybe some PyPI download stats can find the answer. I noticed that numpy doesn't post i686 wheels any more. But given you're opposed and we're so close to v3.0, I'm inclined to continue as we are then.

[henryiii]

I wouldn't change the meaning of auto, I would just set auto64 as the default on at least Linux. I wonder how many of those projects actually want 32-bit support and how many just do it because it's the default. Fine not to make a last-minute change though.

[henryiii]

Or add a new "native" mode, in case someone runs cibuildwheel from a 32-bit machine

[mayeut]

I wouldn't change the meaning of auto, I would just set auto64 as the default on at least Linux.
Or add a new "native" mode

I've not checked but native 32 bits should already be supported (although not tested obviously).
Having a "default" that depends on the platform & native arch would make sense.
Something like (so similar to native except on pyodide/ios & maybe android to come):

Runner	native	default	auto	auto64	auto32
Linux / Intel	x86_64	x86_64	x86_64 i686	x86_64	i686
Linux / Intel	i686	i686	i686		i686
Linux / ARM	aarch64	aarch64	aarch64 armv7hf	aarch64	armv7hf
Linux / ARM	armv7hf	armv7hf	armv7hf		armv7hf
Windows / Intel	AMD64	AMD64	AMD64 x86	AMD64	x86
Windows / Intel	x86	x86	x86		x86
Windows / ARM64	ARM64	ARM64	ARM64	ARM64
macOS / Intel	x86_64	x86_64	x86_64	x86_64
macOS / Apple Silicon	arm64	arm64	arm64	arm64
iOS on macOS / Intel	x86_64_iphonesimulator	x86_64_iphonesimulator	x86_64_iphonesimulator	x86_64_iphonesimulator
iOS on macOS / Apple Silicon	arm64_iphonesimulator	arm64_iphoneos arm64_iphonesimulator	arm64_iphoneos arm64_iphonesimulator	arm64_iphoneos arm64_iphonesimulator

[joerick]

I am a bit hesitant... if we end up with a situation where the 'auto' keyword is not the default, this feels quite confusing to me. I think the important decision is what cibuildwheel does by default, and then the definition of 'auto' can flow from this.

If we wanted to we could make a new keyword like 'all-native' that could include all the archs that are supported by the CPU.

[henryiii]

I don’t think “auto” needs to be the default. Especially if we added a “default”. It would be weird to have “auto” as the default and not “default”, but we could switch to it over time. Also, if someone specifies "auto" explicitly, we shouldn't change what that means, while we can change a default.

We could remove the need for a separate setting if we made “native” in iOS still mean both simulator and device, as it special, as there is no native device platform. then we could move the default to “native”, with the option of somebody setting “auto” to get back to the old default.

I wouldn’t change the default in 3.0, but we could warn that it’s changing soon if that’s what we want to do.

[henryiii]

I'm going to propose something, PR incoming.

[joerick]

In thinking about #2453, I had not realised that actually i686 doesn't appear in https://peps.python.org/pep-0011/ - I'm struggling to find what actually is the status of i686 support in CPython.

[joerick]

As noted in #2453 (comment) I'm not sure about moving the default away from auto and thus making archs = "auto" the way to target more architectures.

How about a new keyword host - meaning all the architectures the host CPU natively supports. And host32 for just the 32-bit variants?

Runner	native/auto	host	host32
Linux / Intel	x86_64	x86_64 i686	i686
Linux / ARM	aarch64	aarch64 armv7l	armv7l
Windows / Intel	AMD64	AMD64 x86	x86
Windows / ARM64	ARM64	ARM64
macOS / Intel	x86_64	x86_64
macOS / Apple Silicon	arm64	arm64
iOS on macOS / Intel	x86_64_iphonesimulator	x86_64_iphonesimulator
iOS on macOS / Apple Silicon	arm64_iphoneos arm64_iphonesimulator	arm64_iphoneos arm64_iphonesimulator

[henryiii]

I really like auto32 and auto64; we should not require someone who doesn't work on building cibuildwheel to know the names of the architectures; it's really weird that some platforms share the same names (unix and macOS Intel 64-bit), while others are different (Windows), and on ARM they are all different. auto64 and auto32 get rid of that and let you just specify what you want. I personally don't bother to look up the names and just use auto32/auto64 if I want to split the 64-bit and 32-bit builds.

There are two options, I believe:

Option 1

We move the default to "native". We leave "auto"/"auto64"/"auto32" alone. This doesn't break anyone that is explicitly setting the architectures, it just drops the 32-bit builds from the default.

Not everyone pins cibuildwheel, especially for minor versions, so I like this solution.

The downside is we are kind of relying on the handy coincidence that both 32-bit builds happen to be going away. If there was some platform that had two architectures that were both popular, we might want to build for both by default.

Option 2

I think we could change the meaning of "auto": it could mean "build the best architecture" available for the current system. The default of "auto" could remain, and anyone setting "auto" explicitly would get the 32-bit win/linux builds removed. "auto32" would remain the same, it would built the best 32-bit architecture available for the current system.

If you want to support both cibuildwheel before and after we introduce this, setting tool.cibuildwheel.archs = ["auto64", "auto32"] would be identical before and after this change.

Runner	auto	auto64	auto32
Linux / Intel 64	x86_64	x86_64	i686
Linux / Intel 32	i686	i686
Linux / ARM 64	aarch64	aarch64	armv7hf
Linux / ARM 32	armv7hf		armv7hf
Windows / Intel 64	AMD64	AMD64	x86
Windows / Intel 32	x86		x86
Windows / ARM64	ARM64	ARM64
macOS / Intel	x86_64	x86_64
macOS / Apple Silicon	arm64	arm64
iOS on macOS / Intel	x86_64_iphonesimulator	x86_64_iphonesimulator
iOS on macOS / Apple Silicon	arm64_iphoneos arm64_iphonesimulator	arm64_iphoneos arm64_iphonesimulator

---

I originally thought of and liked option 1, but I think I really like option 2.

I don't like introducing new terms (we already have enough), or deprecating/changing the names of terms in heavy use. Even if "auto" became just the best arch, instead of all arches, I think auto32 is still clear. Before, auto was the union of auto64 | auto32, now (option 2) it is equivalent to auto64 on a 64-bit system, and auto32 on a 32-bit system, which I really like.

[henryiii]

If everyone likes option 2, do we want to do it in 3.1, or would we like to go ahead and do it now, and extend the RC period a couple of days? I don't like the mixed manylinux images either, so it really is a good time to make such a change if we are all in agreement on how to do it. People upgrading to 3.0 will be more likely to be checking for missing wheels than some minor upgrade, and 3.0's change of the default manylinux images for 64-bit only will possibly confuse people who are not expecting both images to build by default.

BTW, NumPy still makes Win32 wheels, but not 32-bit Linux. Maybe we could do the Linux drop first?

[joerick]

I like option 2 as well :)

So I think we're saying-

auto - the default architectures for this machine, as decided by cibw maintainer team
auto64 - the 64-bit architecture for this machine
auto32 - the 32-bit architecture variant for this machine, if it exists.

All the archs that the machine natively supports is auto64 auto32.

It's fewer keywords, and when used, it looks like what it does. Nice idea henryiii!

I also like that we keep some flexibility in our definition of auto - like, say if we need to do something with x86_64 architecture variants, we can flex our definitions to adapt, which would be harder if the default is native.

I'm still interested in doing it now, if we can reach a consensus. Like you say, while users are looking at manylinux images to upgrade to manylinux_2_28, it's a really good time to make a backward-incompatible change.

[Czaki]

Hm. I think that dropping Linux 32 bits from default is reasonable. From long time I do not see 32-bits linux python.

For windows. I know that many people installed 32-bits python on 64-bits system in the past. But do not know if it still happens.

Maybe the best option could be to check PyPi download stat to check if the feeling, that it is not popular, is correct.