ENH: Poll: availability for 32bit Windows scipy binaries in future?

[carlkl]

Is your feature request related to a problem? Please describe.

Right now Windows 32-bit scipy builds are available for python versions up to 3.9, but not for python-3.10. See the discussion in:
https://mail.python.org/archives/list/scipy-user@python.org/thread/FVBL6G24VXC5D75K3EXQF772OJAF4IGW/ and
https://mail.python.org/archives/list/scipy-dev@python.org/thread/6HJSYSXOSHIGUO5IAZIMRGKJN4JYAJOY/

In near future scipy-1.9 will be build with the help of scipy-meson. The status at present is: On Windows 32-bit builds won't be possible for scipy >= 1.9 as long as no appropriate UCRT enabled 32-bit toolchain GCC/GFortran compiler is available.

Q: Is it worth the effort to develop and maintain an UCRT based 32-bit toolchain? To get an answer for this question, it would be important to know how much demand there will be for 32-bit builds in the near future.

Here is the poll:

who needs to rely on 32-bit scipy builds in the near future?

Describe the solution you'd like.

Development of an 32-bit compiler toolchain for Windows suitable to build scipy 32-bit Windows binaries.

Describe alternatives you've considered.

Drop win32 support for scipy (Windows).

Additional context (e.g. screenshots, GIFs)

No response

[tupui]

Hi @carlkl, thank you for continuing this discussion. What is still missing is an explanation of the need from a user perspective. On the mailing list I read

We have a framework that supports win32, win64, Linux

Which to me does not answer the question. What is the need for 32 bits? What is the application that needs it, etc.

[rkern]

Excel is the big one.

[carlkl]

@tupui, this poll is targeting possible users for win32 32-bit wheels.
I hope to get a better feel for whether 32-bit Windows is still a thing or not.

[carlkl]

BTW: 32bit is still a thing if you consider pyodide/pyscript, as wasm is 32bit today. This is not directly related to my poll, but could be mentioned.

[tupui]

That was my question. What are people using 32 bits for these days?

[carlkl]

Wild guess: accessing hardware still may need 32bit binaries.

[rkern]

Proprietary COM DLLs (which frequently are for driving hardware).

[carlkl]

related issue: #15836

[sturlamolden]

Is it impossible to compile for 32-bit using ifort and icc/msvc? If the issue at hand is supporting proprietary COM/ActiveX stuff (pywin32?) then why not delegate this to the vendor? Do we have to cater for proprietary COM objects by providing free binaries? As long as the code compiles, can they not build SciPy themselves? If I were selling some ActiveX object to use with Excel and VBA, it would also be my responsibility to provide a Python interpreter with SciPy installed. I would not expect the community to do this for me.

[rkern]

If we're not building 32-bit binaries ourselves, it is very, very likely that scipy will stop being buildable in that environment sooner or later.

[sturlamolden]

Not supporting Excel in the sence of not being buildable at all is a bad idea IMHO, but I don’t think we need to provide free binaries.

[rkern]

Please read the issue description. The problem is that it's not buildable at all for Python 3.10. The effort of actually publishing the binary artifacts is not the issue.

[rgommers]

The problem is that it's not buildable at all for Python 3.10. The effort of actually publishing the binary artifacts is not the issue.

I don't think that's true:

• with MSVC + Intel Fortran you can build it,
• with Cygwin/MinGW you can also build it for local use,
• 32-bit Windows wheels for Python 3.10 are available at https://www.lfd.uci.edu/~gohlke/pythonlibs/#scipy

The issue is specifically that we do not have a suitable compiler toolchain right now to build wheels we can distribute on PyPI.

I have a half-written summary with more context that the above, I'll try to finish that up after my next meeting.

If we're not building 32-bit binaries ourselves, it is very, very likely that scipy will stop being buildable in that environment sooner or later.

This is a valid concern indeed. The number of issues we have that's specific to 32-bit Windows is actually very low, and with 64-bit Windows + 32-bit Linux jobs we catch most things. That said, I'd like to keep a dedicated 32-bit Windows test job in CI.

[rgommers]

Here it is: https://discuss.scientific-python.org/t/releasing-or-not-32-bit-windows-wheels/282. With a link back to this issue and a request to post use cases here.

[krishna4all]

32 bit Windows is still under use and supported by the Python foundation (even if its the most modern 3.11 beta), Numpy also has win32 binaries for python 3.10. We have frameworks and libraries which support win32. Our libraries depend on scipy. It would be very helpful to have win32 binaries for all python versions in the future.

[rgommers]

Thanks @krishna4all. Just to confirm, your use case is the same one as brought up on the mailing list (link to thread) right, that was you?

[krishna4all]

Hello Ralf, Its one and the same. Regards Krishna

…

On Tue, Jun 7, 2022 at 10:30 PM Ralf Gommers ***@***.***> wrote: Thanks @krishna4all <https://github.com/krishna4all>. Just to confirm, your use case is the same one as brought up on the mailing list (link to thread ***@***.***/thread/6HJSYSXOSHIGUO5IAZIMRGKJN4JYAJOY/>) right, that was you? — Reply to this email directly, view it on GitHub <#16286 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABOSDGQT3S4TP3G723XSS4LVN65Q5ANCNFSM5XBG7MGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[patou01]

Hi,

Not sure how much of an edge case I am as a user... I'm the maintainer for the internal test framework for the company I work for and with a major update wanted to move to a more recent version of python (ie 3.10, up from 3.7), and it seems some of our libraries don't work with 64 bit, I'm not 100% sure if it's fixable on our side (sits in the COM interface which is not something I master at all). It's to try and communicate with an OPC server in a somewhat antique way.

Which leaves me with 2 options as far as I can tell:

1. Use python 3.9 instead of 3.10, the EOL is probably good enough, we don't seem to need features from 3.10, so probably good enough. This is the easiest so I'll do that, at least initially.
2. Storing the wheels locally, which comes with a few knock-on effects like pycharm apparently not figuring out these requirements.txt if we add wheels, and whatever else I might discover later. If we were hosting our own index this would not be an issue.

I assume you'll find some other users that try to modernize their setup now and then and will come across this. The question is when you'll get them, since these setups are hardly ever updated, so maybe you shouldn't care too much about them either. You might also end up getting these questions when people search on stackoverflow and get a python 3.10+ answer in the future, as I guess it still has a low adoption rate.

To me it's not shocking to drop support for 32 bits, as long as it can easily be figured out why pip is not able to install it, it seems currently it's trying a bunch of versions while I'd expect it to be able to figure out that python 3.10 and win x86 is not possible. (could be user error there)

Not sure this brings any value to you :)

[rgommers]

Thanks @patou01. Yes, this is useful input.

To me it's not shocking to drop support for 32 bits, as long as it can easily be figured out why pip is not able to install it

Unfortunately, this is not so easy. It will try to build from source (there's no good way to avoid this), and then it'll likely fail with some obscure error. We could implement a configuration check to fail straight away when trying to build from source (perhaps bypassable via an opt-in flag).