Describe the bug
stringzilla 5.1.2 is missing both cp311 Windows wheels:
stringzilla-5.1.2-cp311-cp311-win_amd64.whlstringzilla-5.1.2-cp311-cp311-win32.whl
Every other Python and platform combination in that release has its wheels, including cp311 on macOS, Linux and win_arm64, and win_amd64 for cp310, cp312, cp313 and cp314. See https://pypi.org/project/stringzilla/5.1.2/#files
| Release |
cp311 win_amd64 |
cp311 win32 |
total files |
| 5.1.1 |
present |
present |
104 |
| 5.1.2 |
missing |
missing |
92 |
This looks like the same failure as #319, where cp311 Linux wheels went missing from 4.6.2. The per-version build matrix you introduced to fix that is in place and cp311 is listed:
build_wheels_stringzilla_windows_x86:
runs-on: windows-2022
strategy:
fail-fast: false
matrix:
python-version: ["310", "311", "312", "313", "314"]So the matrix is not the problem this time. With fail-fast: false a single failing builder does not stop the others, and the release publishes with the remaining wheels. Nothing appears to check that the uploaded set matches the matrix before publishing, so one flaky builder silently ships an incomplete release.
Downstream effect: stringzilla reaches many people indirectly through albumentations -> albucore -> stringzilla>=3.10.4, so this hits users who never installed it on purpose. On Windows with Python 3.11 pip finds no compatible wheel, falls back to the sdist, and the build fails with "Microsoft Visual C++ 14.0 or greater is required" on any machine without Build Tools. It blocked first-run setup for our Windows users until we pinned 5.1.1.
Steps to reproduce
On Windows with Python 3.11 (x86-64), in a clean venv:
python -m pip install stringzilla
pip downloads stringzilla-5.1.2.tar.gz instead of a wheel and tries to build it. On a machine without Visual C++ Build Tools it fails with "Microsoft Visual C++ 14.0 or greater is required".
python -m pip install --prefer-binary stringzilla installs 5.1.1 from a wheel, which confirms the missing artifact is the only cause.
Expected behavior
pip install stringzilla on Windows with Python 3.11 installs a wheel, as it does for every other supported Python version.
Two asks:
- Could cp311 win_amd64 and win32 wheels be published for 5.1.2, or in the next release? PyPI does allow adding distribution files to an existing version, which would fix it for everyone still resolving a >= constraint without waiting for a new release.
- Would it be worth failing the publish step when the uploaded wheel set does not match the build matrix? fail-fast: false is right for getting full feedback from a build, but it does mean an incomplete release can ship quietly, which is now the second time cp311 has gone missing this way.
StringZilla version
v5.1.2
Operating System
Windows 10 and Windows 11
Hardware architecture
x86
Which interface are you using?
Python bindings
Contact Details
peter@addaxdatascience.com
Are you open to being tagged as a contributor?
Is there an existing issue for this?
Code of Conduct
Describe the bug
stringzilla5.1.2 is missing both cp311 Windows wheels:stringzilla-5.1.2-cp311-cp311-win_amd64.whlstringzilla-5.1.2-cp311-cp311-win32.whlEvery other Python and platform combination in that release has its wheels, including cp311 on macOS, Linux and
win_arm64, andwin_amd64for cp310, cp312, cp313 and cp314. See https://pypi.org/project/stringzilla/5.1.2/#filesThis looks like the same failure as #319, where cp311 Linux wheels went missing from 4.6.2. The per-version build matrix you introduced to fix that is in place and cp311 is listed:
So the matrix is not the problem this time. With fail-fast: false a single failing builder does not stop the others, and the release publishes with the remaining wheels. Nothing appears to check that the uploaded set matches the matrix before publishing, so one flaky builder silently ships an incomplete release.
Downstream effect: stringzilla reaches many people indirectly through albumentations -> albucore -> stringzilla>=3.10.4, so this hits users who never installed it on purpose. On Windows with Python 3.11 pip finds no compatible wheel, falls back to the sdist, and the build fails with "Microsoft Visual C++ 14.0 or greater is required" on any machine without Build Tools. It blocked first-run setup for our Windows users until we pinned 5.1.1.
Steps to reproduce
On Windows with Python 3.11 (x86-64), in a clean venv:
python -m pip install stringzilla
pip downloads stringzilla-5.1.2.tar.gz instead of a wheel and tries to build it. On a machine without Visual C++ Build Tools it fails with "Microsoft Visual C++ 14.0 or greater is required".
python -m pip install --prefer-binary stringzilla installs 5.1.1 from a wheel, which confirms the missing artifact is the only cause.
Expected behavior
pip install stringzilla on Windows with Python 3.11 installs a wheel, as it does for every other supported Python version.
Two asks:
StringZilla version
v5.1.2
Operating System
Windows 10 and Windows 11
Hardware architecture
x86
Which interface are you using?
Python bindings
Contact Details
peter@addaxdatascience.com
Are you open to being tagged as a contributor?
.githistory as a contributorIs there an existing issue for this?
Code of Conduct