Reputation: 174
I am attempting to package a custom built Python wheel package for offline installation, which indirectly depends on cffi
. To do so, I call python3 -m pip download my-custom-package -d package-content
. I then create a 7zip self extracting installer that uses a Windows batch script to handle the installtion by using the --find-links
functionality of pip
.
I constrain my package's setup.py
to Python 3.6, and use the Python 3.6 interpreter to run the pip download
command. I was under the impression that this would retrieve wheel packages capable of being installed on any version of Python 3.x newer than 3.6 (in most cases).
cffi-1.15.1-cp36-cp36m-win_amd64
is fetched when packaging the offline installer for Windows x86_64, and is able to be installed on Python 3.6 through 3.9. However, when I attempt to install it on Python 3.10, I get the following output:
ERROR: cffi-1.15.1-cp36-cp36m-win_amd64.whl is not a supported wheel on this platform.
If I change the name of the file to cffi-1.15.1-
cp310-
cp310m-win_amd64.whl
, then it suddenly installs correctly (and is useable). This leads me to believe that there is nothing internal to the file indicating that it is not compatible with Python 3.10, but rather pip
is parsing the ABI
from the filename, and barfing on it.
Is this a known bug with pip
? My pip
version on the packaging side is 21.3.1
, and on the installation side is 23.0.1
. My current plan is to run the pip
download command multiple times, specifying each Python minor version between 3.6 and 3.10. This is cumbersome however, and if there is a documented bug explaing this as isolated specifically to cffi-1.15.1-cp36-cp36m-win_amd64
, then I could possible look into alternate, more elegant, solutions. Is it perhaps a limitation of the cp3x
ABI
?
Upvotes: 0
Views: 1187