search

dqrobotics / python

The DQ Robotics library in Python
https://dqrobotics.github.io
GNU Lesser General Public License v3.0
26 stars 9 forks source link

[BUG] Installation issues with universal wheels. #56

Closed mmmarinho closed 9 months ago

mmmarinho commented 9 months ago

This is to track recent issues that can be traced to the newly built universal2 wheels. I am not sure when those begun to be compiled by the x86_x64 GithubActions machines, but they are not in fact universal2 and that is causing problems.

To replicate this issue, in a M2 MacbookPro running Ventura 13.6.3, we simply install the latest version of the library. It will, as shown below, install macosx_10_15_universal2.whl. I suppose that the versioning issue of not having a 10_15 wheel available in arm64 caused the installation to default to the universal2 wheel.

(.venv) murilos-toaster:py311arm64 mmm$ python3 -m pip install dqrobotics --pre
Collecting dqrobotics
  Obtaining dependency information for dqrobotics from https://files.pythonhosted.org/packages/0b/3a/cbdffd1a74fb10a69f2b3ccb2333537ad922028551ab6d1ff152c6302a93/dqrobotics-23.4.0a21-cp311-cp311-macosx_10_15_universal2.whl.metadata
  Using cached dqrobotics-23.4.0a21-cp311-cp311-macosx_10_15_universal2.whl.metadata (2.1 kB)
Requirement already satisfied: numpy in ./.venv/lib/python3.11/site-packages (from dqrobotics) (1.26.3)
Using cached dqrobotics-23.4.0a21-cp311-cp311-macosx_10_15_universal2.whl (611 kB)
Installing collected packages: dqrobotics
Successfully installed dqrobotics-23.4.0a21

That would be fine as long as it worked, but the output of the simplest of scripts, e.g.

from dqrobotics import *

print(DQ([0,1,2,3,4,5,6,7]))

is an error, such as,

Traceback (most recent call last):
  File "/Users/user/PycharmProjects/py311arm64/py311arm64.py", line 1, in <module>
    from dqrobotics import *
  File "/Users/user/PycharmProjects/py311arm64/.venv/lib/python3.11/site-packages/dqrobotics/__init__.py", line 26, in <module>
    from dqrobotics._dqrobotics import *
ImportError: dlopen(/Users/user/PycharmProjects/py311arm64/.venv/lib/python3.11/site-packages/dqrobotics/_dqrobotics.cpython-311-darwin.so, 0x0002): tried: '/Users/user/PycharmProjects/py311arm64/.venv/lib/python3.11/site-packages/dqrobotics/_dqrobotics.cpython-311-darwin.so' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64')), '/System/Volumes/Preboot/Cryptexes/OS/Users/user/PycharmProjects/py311arm64/.venv/lib/python3.11/site-packages/dqrobotics/_dqrobotics.cpython-311-darwin.so' (no such file), '/Users/user/PycharmProjects/py311arm64/.venv/lib/python3.11/site-packages/dqrobotics/_dqrobotics.cpython-311-darwin.so' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64'))

Process finished with exit code 1

The wheel is being built x86_64 but self entitling as universal2 and messing up the pip installation. The simplest solution is forcing a rename to the wheels that are output by x86_64 GithubAction runners. However, at this stage, I do not know why the wheels are being built as universal2, so such a naive solution might cause more problems.

mmmarinho commented 9 months ago

This was a problem that started happening somewhere between https://pypi.org/project/dqrobotics/21.4.0a75/#files and https://pypi.org/project/dqrobotics/20.4.0.79/#files so it's an old issue that never surfaced (or nobody complained about).

It can be tracked to other repositories such as https://github.com/pypa/setuptools/issues/2520

Building a truly universal2 wheel is something that can be considered, but at this stage it's better to change the naming of the wheels being built by the Github-hosted runners to represent what is actually being built, i.e. x86_x64, in particular because we already have a self-hosted machine building the arm64 wheels.