Repository navigation
win32 wheels missing on PyPI #7443
Description
Activity
Version 9.5.0 still had 32-bit wheels
So this is intended?
In contrast to linux, the 32-bit version of Python is still used on Windows due to compatibility. And Python still provides 32-bit Windows releases, even for 3.12.0 there is one: https://www.python.org/downloads/release/python-3120/
Yes, this is intended, see the 10.0.0 release notes and #6941.
Pillow should still work on 32-bit, you just have to build it from source yourself. See https://pillow.readthedocs.io/en/stable/installation.html#building-from-source for more information.
- changed the title
[-]win32 wheels missing on pypi[/-][+]win32 wheels missing on PyPI[/+]on Oct 5, 2023 While I completely understand the decision for Linux with below 0.1% of installs, Windows is quite different. More than 9000 installs in 7 days is a big number.
In the discussion mentioned in issue 6941 a pyca/cryptography developer even notes the difference between Linux and Windows: https://discuss.python.org/t/dropping-32-bit-packages/5476/17
The problem is, while I would love to switch to 64-bit on Windows, one of the legacy systems (Simatic SDK) can only be automated using a win32 COM library which can only be imported using 32-bit Python. And this is not something that can be changed with a few hours of coding, because there is no 64-bit alternative.
In my time as a freelancer I've seen quite a few of this kind of legacy system on Windows, so I don't think this is an unusual setting. My guess is, that this is the reason python still provides win32 binaries.Building from source is also quite different on Windows, as you manually need to install a C++ compiler and all the required libraries on all nodes. Windows doesn't have a builtin state-of-the-art package manager like apt.
See also:
https://discuss.python.org/t/consider-downgrading-windows-32-bit-from-tier-1-to-tier-2-or-tier-3-in-python-3-13/33719/9
https://discuss.python.org/t/consider-downgrading-windows-32-bit-from-tier-1-to-tier-2-or-tier-3-in-python-3-13/33719/21Reacted by Christoph GohlkeMore than 9000 installs in 7 days is a big number.
I'm not sure, we don't know where these installs are coming from, I suspect a lot are from CI. It's dwarfed by the more than 7.3 million installs for everything else.
Getting fresh numbers via
pypinfo --days 7 --limit 100 pillow==9.5.0 file > 1000-9.5.0.txt && grep win32*.whl:file download_count Pillow-9.5.0-cp37-cp37m-win32.whl 5,980 Pillow-9.5.0-cp38-cp38-win32.whl 1,377 Pillow-9.5.0-cp311-cp311-win32.whl 1,303 Pillow-9.5.0-cp310-cp310-win32.whl 764 Pillow-9.5.0-cp39-cp39-win32.whl 656 Pillow-9.5.0-cp312-cp312-win32.whl 56 And we can forget EOL 3.7, bringing it down to ~4k.
Comparing with the other Windows wheels for the latest 10.0.1 (via
pypinfo --days 7 --limit 100 pillow==10.0.1 file), the 32-bit proportion is now even lower (before 0.90% - 5.63%, now 0.6%-2.34% and 0.85% overall):file download_count percentage Pillow-10.0.1-cp312-cp312-win_amd64.whl 9,211 99.40 % Pillow-9.5.0-cp312-cp312-win32.whl 56 0.60 % total 9,267 Pillow-10.0.1-cp311-cp311-win_amd64.whl 184,474 99.30 % Pillow-9.5.0-cp311-cp311-win32.whl 1,303 0.70 % total 185,777 Pillow-10.0.1-cp310-cp310-win_amd64.whl 150,020 99.49 % Pillow-9.5.0-cp310-cp310-win32.whl 764 0.51 % total 150,784 Pillow-10.0.1-cp39-cp39-win_amd64.whl 80,764 99.49 % Pillow-9.5.0-cp39-cp39-win32.whl 656 0.51 % total 656 Pillow-10.0.1-cp38-cp38-win_amd64.whl 57,497 97.66 % Pillow-9.5.0-cp38-cp38-win32.whl 1,377 2.34 % total 58,874 Pillow-10.0.1-*-win_amd64.whl 481,966 99.15 % Pillow-9.5.0-*-win32.whl 4,156 0.85 % total 486,122 Looks like we need to fix the basic installation section of the docs that refers to 32-bit ? https://pillow.readthedocs.io/en/stable/installation.html#basic-installation
E.g.
From
We provide Pillow binaries for Windows compiled for the matrix of supported Pythons in both 32 and 64-bit versions in the wheel format. These binaries include support for all optional libraries except libimagequant and libxcb. Raqm support requires FriBiDi to be installed separately:
To
We provide 64-bit Pillow wheels for Windows for supported Python versions. 32-bit Pillow wheels are no longer provided as of Pillow version 9.5.0. These wheels include support for all optional libraries except libimagequant and libxcb. Raqm support requires FriBiDi to be installed separately:
Reacted by Hugo van KemenadeThis has been partly done in latest already, with #7347 - https://pillow.readthedocs.io/en/latest/installation.html#basic-installation
Reacted by Jeffrey 'Alex' ClarkBuilding from source is also quite different on Windows, as you manually need to install a C++ compiler and all the required libraries on all nodes. Windows doesn't have a builtin state-of-the-art package manager like apt.
As per the instructions, the https://github.com/python-pillow/Pillow/tree/main/winbuild scripts should help with this.
If you would like something even simpler, you could take advantage of the fact that we use CI jobs to create our wheels. A simple modification to change the architecture (and drop PyPy), and an artifact is uploaded to https://github.com/radarhere/Pillow/actions/runs/6445067119 with 32-bit Windows wheels inside.
Reacted by Ondrej BaranovičAs per the instructions, the https://github.com/python-pillow/Pillow/tree/main/winbuild scripts should help with this.
If you would like something even simpler, you could take advantage of the fact that we use CI jobs to create our wheels. A simple modification to change the architecture (and drop PyPy), and an artifact is uploaded to https://github.com/radarhere/Pillow/actions/runs/6445067119 with 32-bit Windows wheels inside.
The problem is that our infrastructure doesn't base on Github Actions but Gitlab CI and/or Jenkins. So these CI jobs are not applicable for us.
And the instructions are quite extensive, nothing we can do every time we want to just install the package in a Jenkins job.I think the main problems will arise, when other packages that have Pillow as dependency, raise their minimum requirement to >=10.0.0. Then the intermediate package can't be updated to the latest version. And if that latest version includes security patches, it basically renders the intermediate package unusable, on a fully supported python version. This might even result in developers not being able to use a supported python version (in about 4 years, when support for python 3.11 ends).
What is the reason for the ending support for 32 bit Windows platform? Is the maintenance required for it so time consuming? Usually building for 32 bit Windows is not that different than for 64 bit Windows.
Agree the documentation is a bit light here too: https://pillow.readthedocs.io/en/stable/releasenotes/10.0.0.html#bit-wheels. I'd expect to see an issue referenced, or explanation given. Something more than "no longer provided" with the tacit assumption everyone is aware "the passage of time erases all things" should be provided 😄 If I recall correctly, it may have been that @hugovk noticed no one was downloading them anymore.
Starting to remove support for 32-bit Linux wheels was suggested when deadsnakes decided not to support Python 3.12 on Bionic, the last 32-bit Ubuntu.
The low download count on Windows was noted, and then it was suggested to drop 32-bit wheels entirely.
Reacted by Alexander PiskunI haven't put a lot of thought into this but, at a glance, it looks like M$ will support Windows 10 (the last of their 32-bit operating systems) until 2025 and so we may want to consider re-adding 32-bit wheels until then. Given this is the case, we may expect a lot of questions about 32-bit installation failures. It also seems likely there will come a time when this matters a lot less, but perhaps today is not that day. With the next release due, this may be a good time to decide one way or another. 🤷
- Reacted by Jeffrey 'Alex' Clark
Pillow 10.2.0 has been released with Windows 32-bit wheels.
Reacted by Jeffrey 'Alex' ClarkWoo hoo!
Since version 10.0.0 there are no wheels for 32-bit version of Windows present on pypi. Version 9.5.0 still had 32-bit wheels.
Pillow 9.5.0 vs Pillow 10.0.1 (search for win32)
We still use 32-bit Python on Windows (64-bit), as some old COM components (32-bit) require the use of the matching Python. They can't be called from a 64-bit Python.