2.13.4 doesn't get compiled from source by pip
aptalca opened this issue · comments
When I try to install rapidfuzz on an OS where there are no prebuilt wheels, pip installs 2.13.3 instead (compiled from source).
I ran into this issue in the past with other projects and I believe the issue is incorrect pypi cache, where it's missing the tarball for the latest version, so it defaults to the previous version instead.
Here's a log snippet of trying to compile 2.13.4 from source with the --no-binary option:
Using pip 22.3.1 from /usr/lib/python3.10/site-packages/pip (python 3.10)
DEPRECATION: --no-binary currently disables reading from the cache of locally built wheels. In the future --no-binary will not influence the wheel cache. pip 23.1 will enforce this behaviour change. A possible replacement is to use the --no-cache-dir option. You can use the flag --use-feature=no-binary-enable-wheel-cache to test the upcoming behaviour. Discussion can be found at https://github.com/pypa/pip/issues/11453
ERROR: Could not find a version that satisfies the requirement rapidfuzz==2.13.4 (from versions: 0.0.6, 0.0.7, 0.0.8, 0.1.0, 0.1.1, 0.2.0, 0.2.1, 0.2.2, 0.3.0, 0.4.0, 0.5.0, 0.5.1, 0.5.2, 0.5.3, 0.6.0, 0.6.1, 0.6.2, 0.6.3, 0.6.4, 0.6.5, 0.6.6, 0.6.7, 0.6.8, 0.7.0, 0.7.1, 0.7.3, 0.7.4, 0.7.5, 0.7.6, 0.7.7, 0.7.8, 0.7.9, 0.7.10, 0.7.11, 0.7.12, 0.8.0, 0.8.1, 0.8.2, 0.9.0, 0.9.1, 0.10.0, 0.11.0, 0.11.1, 0.11.2, 0.11.3, 0.12.0, 0.12.1, 0.12.2, 0.12.3, 0.12.4, 0.12.5, 0.13.0, 0.13.1, 0.13.2, 0.13.3, 0.13.4, 0.14.0, 0.14.1, 0.14.2, 1.0.0, 1.0.1, 1.0.2, 1.1.0, 1.1.1, 1.1.2, 1.2.0, 1.2.1, 1.3.0, 1.3.1, 1.3.2, 1.3.3, 1.4.0, 1.4.1, 1.5.0, 1.5.1, 1.6.0, 1.6.1, 1.6.2, 1.7.0, 1.7.1, 1.8.0, 1.8.1, 1.8.2, 1.8.3, 1.9.0, 1.9.1, 2.0.0, 2.0.1, 2.0.2, 2.0.3, 2.0.4, 2.0.5, 2.0.6, 2.0.7, 2.0.8, 2.0.9, 2.0.10, 2.0.11, 2.0.12, 2.0.13, 2.0.14, 2.0.15, 2.1.0, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.2.0, 2.3.0, 2.4.1, 2.4.2, 2.4.3, 2.5.0, 2.6.0, 2.6.1, 2.7.0, 2.8.0, 2.9.0, 2.10.0, 2.10.1, 2.10.2, 2.10.3, 2.11.0, 2.11.1, 2.12.0, 2.13.0, 2.13.1, 2.13.2, 2.13.3)
ERROR: No matching distribution found for rapidfuzz==2.13.4
Here's a demonstration of trying to install rapidfuzz on alpine arm32v7 in docker, and pip installs 2.13.3: https://hastebin.com/yawizesixo.sql
Here's a demonstration of trying to install rapidfuzz on x86_64 with --no-binary rapidfuzz in docker and it installs 2.13.3: https://hastebin.com/comotehake.sql
While this is not your project's fault, as the tarball is indeed listed on pypi (https://pypi.org/project/rapidfuzz/#files), it somehow isn't found by pip (perhaps pypi cache?).
I don't know how to report the issue to pypi so I'm reporting here in the hopes that you have some channel to communicate with them through, or perhaps a way for your team to force a pypi cache update.
Thanks
Unrelated, but apparently your build always fails (installs the pure Python fallback), which is likely not what you want. Do you have a C++ compiler installed in the container?
Right, the above logs were just for demonstrating the version pip attempts to install. In the actual builds, we include the proper deps: https://github.com/linuxserver/wheelie/blob/main/Dockerfile
For context, we host a wheel repo that our docker images can use to significantly cut down on build time: https://wheel-index.linuxserver.io/
Regarding the broken cache for the sdist: I can reproduce this as well, but I have no way (I am aware of) to force a cache update. I assume this could be reported in https://github.com/pypa/pypi-support or https://github.com/pypi/warehouse.
Seems the cache got updated:
python3.11 -m pip install --no-binary rapidfuzz rapidfuzz==2.13.4
Defaulting to user installation because normal site-packages is not writeable
Collecting rapidfuzz==2.13.4
Downloading rapidfuzz-2.13.4.tar.gz (843 kB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 843.4/843.4 kB 1.2 MB/s eta 0:00:00
Yeah, they mentioned dns cache as the underlying problem in that warehouse issue, which apparently has a ttl of 24 hours