Repaired Wheel Doesn't Work with py-limited-api and Future Python Versions
WillAyd opened this issue · comments
I was able to create a wheel with py-limited-api=38 . On other platforms, the repaired wheel is still installable on Python 3.9 / 3.10, but I've noticed on Windows that when trying to use the repaired wheel proc mon shows entries like ...\site-packages\<package_name>\python38.dll NAME NOT FOUND
How did you build your extension module? If you built it correctly, you should be linking to python3.dll and not python38.dll. See whether pypa/setuptools#1248 helps.
Great thanks for the info. I at least am already doing what is described in that article. If you cared to look (its a bit complicated) here are the relevant pieces from my project:
source file:
https://github.com/WillAyd/hyperarrow/blob/windows-wheels/python/hyperarrow/hyperarrow.cpp
setup.py:
https://github.com/WillAyd/hyperarrow/blob/windows-wheels/python/setup.py
CMake is being used as the main build tool and has a custom python target defined in the top level of the package hierarchy that will call setup.py bdist_wheel --py-limited-api=cp38
I do wonder if setting the limit of 38 is what's causing it to search for the 38 dll instead of just a generic Python, though as mentioned I haven't seem to run across this issue with either auditwheel or delicate.
This looks like an issue with the build procedure on Windows rather than delvewheel itself, but I'll see whether I can help. If you provide a link to or upload a wheel that you've been testing, I might be able to point you in the right direction.
The wheel is a too big to upload in the comments but I think you can download from here temporarily:
Thanks, I looked through the wheel and I can confirm that libhyperarrow.pyd is correctly linked to python3.dll. The issue arises from the fact that the arrow_python.dll dependency is linked to python38.dll. I'm not sure whether you build arrow_python.dll yourself or download it from elsewhere. Either way, you'll need a build of of arrow_python.dll that's built against the Python 3.8 limited API.
As a side note, I noticed an oddity in the wheel where there are multiple copies of the dependent libraries - in hyperarrow.libs, hyperarrow, and hyperarrow\tests. delvewheel should be copying libraries only into hyperarrow.libs. Having more copies shouldn't be harmful other than taking up extra space, but I want to know whether this is a delvewheel bug. Did you make the other copies?
Ah that's a great point. I'll have to think about that architecturally. And yea sorry I copied from hyperarrow.libs into hyperarrow as the libraries weren't being found from the default hyperarrow.libs folder
None of this sounds like a delvewheel issue so happy to close this. Thanks again for the support and the awesome tool