No 1.21.4 wheel available for cp310-win32

[fgregg]

numpy 1.22.3 is the first release on pypi to have binary wheels for cpython 3.10 on win32, but setup.cfg says to use 1.21.4

oldest-supported-numpy/setup.cfg

Line 56 in 8f36bbf

numpy==1.21.4; python_version=='3.10' and platform_machine!='loongarch64' and platform_python_implementation != 'PyPy'

[fgregg]

Fixed by #44

[matham]

Did the latest release fix the issue for you? Because it didn't for me (for the dependency I was having an issue with on the CI), and I'm thinking that maybe checking whether platform_machine is x86 is incorrect. Because I don't think it's checking whether python is 32 bit, just whether the OS is 32 bit. Otherwise it doesn't make sense why the latest release is still giving me the issue (and I don't have a 32 bit python to check with handy).

You can see here what is available: https://peps.python.org/pep-0508/#environment-markers

[fgregg]

i think maybe we need sys_platform=win32, but i'm not sure.

[matham]

I've added #47 to clearly show the issue. It seems we cannot differentiate python bitness :( so my type of solution won't work. I can make a PR just bumping the min numpy for Windows if @rgommers approves (and remove the changes from the last PR).

[rgommers]

Argh yes, that rings a bell. We indeed need Python bitness, not x86 platform.

i think maybe we need sys_platform=win32, but i'm not sure.

No, that's not it either - win32 means "Windows" (also 64-bit, despite the 32 in the name).

I can make a PR just bumping the min numpy for Windows if @rgommers approves (and remove the changes from the last PR).

I think (but haven't verified) that we cannot do this. Updating to 1.22.3 would mean that for x86_64 a wheel built against that would work back to 1.22.0, but IIRC there's a runtime check that will prevent it to work with 1.21.x. Maybe you have time to verify that @matham?

[matham]

I think (but haven't verified) that we cannot do this. Updating to 1.22.3 would mean that for x86_64 a wheel built against that would work back to 1.22.0, but IIRC there's a runtime check that will prevent it to work with 1.21.x. Maybe you have time to verify that @matham?

I don't quite understand. Do you mean if I use numpy in e.g. a cython project linking to numpy, it's not runnable with numpy with older minor versions? I don't actually have a project using numpy in this way so I can't really test. I'm just adding these PRs to fix issues with some dependencies (pytables) I was adding mac apple silicon support to.

But, even if that's the case, is the issue that 1.22.0 is just too new? Because we already don't support e.g. 1.20.x that is only a year old. 1.22.0 is only 6 months newer than 1.21.0.

[henryiii]

Do you mean if I use numpy in e.g. a cython project linking to numpy, it's not runnable with numpy with older minor versions?

That's the point of oldest-supported-numpy; you must compile against the oldest supported numpy (minor version) when using something like Cython (not pybind11, FYI). You can't compile against 1.22 and run with 1.21, but you can compile against 1.21 and run with 1.22.

IMO, the system bitness is not interesting when selecting wheels, while the Python bitness is. Is platform_release or platform_version at all helpful on Windows, say with an in statement? I'm also asking around.

[matham]

Is platform_release or platform_version at all helpful on Windows, say with an in statement? I'm also asking around

I compared the (Python equivalent) value of every marker in the table for python 3.7 32 bit and 64 bit and they were identical. So I'm not sure there's a way to detect this.

[rgommers]

C API version did indeed increase from 1.21 to 1.22: https://github.com/numpy/numpy/blob/main/numpy/core/setup_common.py#L46-L47.

Building SciPy against 1.22 and then running its tests against 1.21 gives this error:

RuntimeError: module compiled against API version 0xf but this version of numpy is 0xe

So it looks like we cannot add a 1.22.3 requirement for 32-bit Python on Windows.

The x86 change in gh-44 is probably not wrong (since you cannot run 64-bit Python on 32-bit Windows I think), but I'm inclined to revert it because it doesn't cover the most relevant case (32-bit Python on 64-bit Windows).

The immediate solution is to not use oldest-supported-numpy in your package for Python 3.10 on Windows (manually depend on the NumPy version you want instead).

[matham]

The immediate solution is to not use oldest-supported-numpy in your package for Python 3.10 on Windows (manually depend on the NumPy version you want instead).

But at that point, what is the downside of pinning oldest-supported-numpy to 1.22.3 for 3.10 Windows and not supporting 1.21? That's anyway what you'd need to do if you want to support 32 bit on windows 3.10? Is that that for 64 bits we do want to support 1.21, even if 32 bit is not supported?