Repository navigation
DEP: stop building and testing 32-bit windows #23717
Description
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.
Activity
carlkl commentedon May 21, 2023
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 commentedon May 21, 2023
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 commentedon May 23, 2023
Any idea if/how this would affect people on WASM/pyodide?
rgommers commentedon May 24, 2023
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 commentedon May 24, 2023
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 commentedon May 24, 2023
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 commentedon May 24, 2023
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 commentedon May 24, 2023
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 commentedon May 24, 2023
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.
CI: drop 32-bit Windows Azure testing, adjust 64-bit for Meson
seberg commentedon May 30, 2023
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.)
CI: drop 32-bit Windows Azure testing, adjust 64-bit for Meson
CI: drop 32-bit Windows Azure testing, adjust 64-bit for Meson
CI: drop 32-bit Windows Azure testing, adjust 64-bit for Meson
charris commentedon Aug 13, 2023
Note that there are no 32 windows wheels in the 1.26.0b1 release. Do we want them?
rgommers commentedon Aug 14, 2023
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 thesetup-pythonaction. 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
msdevshellaction, 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 commentedon Aug 14, 2023
@rgommers Sounds good.
pllim commentedon Aug 31, 2023
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
BLD: build wheels for 32-bit Python on Windows, using MSVC
BLD: build wheels for 32-bit Python on Windows, using MSVC [wheel build]
rgommers commentedon Sep 8, 2023
With gh-24671 we should get 32-bit wheels back.
BLD: build wheels for 32-bit Python on Windows, using MSVC [wheel build]
BLD: build wheels for 32-bit Python on Windows, using MSVC [wheel build]
BLD: build wheels for 32-bit Python on Windows, using MSVC [wheel build]
BLD: build wheels for 32-bit Python on Windows, using MSVC [wheel build]
BLD: build wheels for 32-bit Python on Windows, using MSVC [wheel build]