You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the AequilibraE repository we're attempting to the use Pyarrow Cython and C++ API for construction some tables. We can build and use the API successfully, however we're running into issues with packaging and wheel repairs.
I've created a repo to demo this and attached the CI logs.
However we have some questions regarding the wheel repair process,
Should we be repairing the wheel in the first place? As I understand it the repair process involves finding external libs and placing them inside the wheel and correcting the paths. Should we instead be depending solely on the libraries packaged with Pyarrow?
Since the libarrow.so/libarrow.dylib symlinks are created dynamically by Pyarrow depending on the installed version, should we first be using something like install_name_tool to rewrite the version tagged links to the generic ones?
Related to the above, libarrow_python.so/libarrow_python.dylib libs are not version tagged, however the auditwheel and delocate-wheel are both unable to repair them. Is this because the build dependencies are not installed during the repair process?
Are we just going about this wrong? Is there a better way I'm just unaware of?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
In the AequilibraE repository we're attempting to the use Pyarrow Cython and C++ API for construction some tables. We can build and use the API successfully, however we're running into issues with packaging and wheel repairs.
I've created a repo to demo this and attached the CI logs.
https://github.com/Jake-Moss/cython-pyarrow-mwe
logs_24802855078.zip
Because of how Arrow packages Pyarrow, some extra consideration is required when building against PyPi wheels which I believe we've done since we can compile the project (and mwe) locally.
https://arrow.apache.org/docs/python/integration/extending.html#building-extensions-against-pypi-wheels
However we have some questions regarding the wheel repair process,
libarrow.so
/libarrow.dylib
symlinks are created dynamically by Pyarrow depending on the installed version, should we first be using something likeinstall_name_tool
to rewrite the version tagged links to the generic ones?libarrow_python.so
/libarrow_python.dylib
libs are not version tagged, however theauditwheel
anddelocate-wheel
are both unable to repair them. Is this because the build dependencies are not installed during the repair process?Beta Was this translation helpful? Give feedback.
All reactions