DEP: stop building and testing 32-bit windows

[mattip]

See the discussion at https://discuss.python.org/t/dropping-32-bit-packages

The builds are difficult to maintain, suffer bit rot, and are not popular.

Another option is to stop testing f2py on this platform, which is the reason we try to install a fortran compiler. Building NumPy does not require the fortran compiler, it is only for tests.

Edit: not true, wrapping the OpenBLAS library does require the fortran runtime.

[carlkl]

Just to mention one example: Aren't there still a relevant number of users who use python/numpy in together with excel, i.e. pyxll? MS Office 32-bit is still a thing today in many scenarios, despite the fat that if it is no longer the default version during installing for some time now. 32-bit applications are sunsetting now on Windows, this is obvious. But 32-bit support on Windows may be necessary for some time in the future for those who can't switch to 64-bit. And there is no long term support for any version of python / numpy.

[charris]

Looks like Intel is thinking of dropping 32 bit hardware support in the future: https://www.tomshardware.com/news/intel-ponders-transition-to-64-bit-only-x86s-architecture .

[lithomas1]

Any idea if/how this would affect people on WASM/pyodide?

[rgommers]

Any idea if/how this would affect people on WASM/pyodide?

It shouldn't, we have a CI job for Pyodide/Emscriptem and that will continue to work: https://github.com/numpy/numpy/blob/main/.github/workflows/emscripten.yml. I'd expect support for WASM and Pyodide to continue to mature.

[lithomas1]

I thought WASM is 32-bit for now, maybe I'm understanding what the memory64 proposal(https://github.com/WebAssembly/memory64) is supposed to mean?

[rgommers]

Sure, but no one is planning on actively breaking all 32-bit builds I believe. We just need a single CI job that tests that we don't accidentally introduce 64-bit-only things and break 32-bit builds. Users or redistributors may still choose to build them, and this proposal moves 32-bit Windows into the same category as 32-bit Linux on armv7 (Raspberry Pi & co), and some other niche use cases.

@mattip I think your issue description is perhaps a little misleading, in particular the link to your Discourse post from 3 years ago. As I understand it, it is specific to reducing the support status (and our corresponding burden) for 32-bit Windows only. All 32-bit platforms are then supported only on a best-effort basis, we don't create binaries for them but will take patches if they're contributed for a specific platform.

[mattip]

Yes, that is correct. CPython has a concept of support tiers. I propose moving 32-bit windows from Tier 1 to "other platforms". Perhaps we should have our own page of tiered support.

[lithomas1]

That makes sense.
(I thought the proposal was to rip out all the 32-bit compat. Is there any timeline for that?)

At any rate, happy to follow numpy's lead on this for pandas. I personally don't care for 32-bit support too much.

[mattip]

Even if we stop actively supporting 32-bit in wheels and CI, I don't think we should remove 32-bit compatibility for the foreseeable future.

[seberg]

Just to say 👍 if win32 wheels/CI is making trouble (and it seems to be the case right now), there seems to be little reason to not just drop it for now.

(And yes, we still will have 32bit support with CI, just not testing it explicitly for windows, so in an "other platforms" support tier.)

[charris]

Note that there are no 32 windows wheels in the 1.26.0b1 release. Do we want them?

[rgommers]

Ah good question. It should all work again, and we have a regular CI job for it at https://github.com/numpy/numpy/blob/main/.github/workflows/windows_meson.yml#L93. It should be low-overhead, nothing special was needed beyond adding architecture: 'x86' to the setup-python action. So let's re-enable the wheel builds I'd say, since it may save the users that still need it a bunch of trouble.

I'll note that I'm still fine with getting rid of them again if they cause trouble. But here most of the problem was in the mess that's our Azure setup combined with the mess Microsoft makes with activating MSVC. However, with GHA, the msdevshell action, and the meson-python improvements to make it easy to use MSVC, it shouldn't be difficult anymore.

How about we keep this issue closed, because it's about the generic "can/shall we do this" decision, and that trade-off hasn't really changed. And open a new issue to re-enable builds before the next pre-release? I should be able to fix this, but not in the next 2-3 days.

[charris]

@rgommers Sounds good.

[pllim]

Hello! @ngoldbaum pointed me here when I failed to find a win32 wheel for numpy 1.26b. Would be nice if it can be tested downstream before the final release.

xref astropy/astropy#14784 and liberfa/pyerfa#111

[rgommers]

With gh-24671 we should get 32-bit wheels back.