Universal wheel for macOS contains only x86_64 build

[doronz88]

Duplicate of #2154 - Same issue persists in latest version (v5.0.2)
I'm getting the following traceback using latest version on macOS:

Traceback (most recent call last):
  File "/Users/doron/.local/bin/rpcclient", line 7, in <module>
    from rpcclient.__main__ import rpcclient
  File "/Users/doron/dev/rpc-project/src/rpcclient/rpcclient/__main__.py", line 6, in <module>
    from rpcclient.client_factory import DEFAULT_PORT, create_local, create_tcp_client
  File "/Users/doron/dev/rpc-project/src/rpcclient/rpcclient/client_factory.py", line 10, in <module>
    from rpcclient.client import Client
  File "/Users/doron/dev/rpc-project/src/rpcclient/rpcclient/client.py", line 26, in <module>
    from rpcclient.fs import Fs
  File "/Users/doron/dev/rpc-project/src/rpcclient/rpcclient/fs.py", line 14, in <module>
    from rpcclient.darwin.symbol import DarwinSymbol
  File "/Users/doron/dev/rpc-project/src/rpcclient/rpcclient/darwin/symbol.py", line 6, in <module>
    from rpcclient.symbol import Symbol
  File "/Users/doron/dev/rpc-project/src/rpcclient/rpcclient/symbol.py", line 7, in <module>
    from capstone import CS_ARCH_ARM64, CS_ARCH_X86, CS_MODE_64, CS_MODE_LITTLE_ENDIAN, Cs, CsInsn
  File "/Users/doron/Library/Application Support/pipx/venvs/rpcclient/lib/python3.11/site-packages/capstone/__init__.py", line 403, in <module>
    _cs = _load_lib(_path)
          ^^^^^^^^^^^^^^^^
  File "/Users/doron/Library/Application Support/pipx/venvs/rpcclient/lib/python3.11/site-packages/capstone/__init__.py", line 376, in _load_lib
    return ctypes.cdll.LoadLibrary(lib_file)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/homebrew/Cellar/python@3.11/3.11.9_1/Frameworks/Python.framework/Versions/3.11/lib/python3.11/ctypes/__init__.py", line 454, in LoadLibrary
    return self._dlltype(name)
           ^^^^^^^^^^^^^^^^^^^
  File "/opt/homebrew/Cellar/python@3.11/3.11.9_1/Frameworks/Python.framework/Versions/3.11/lib/python3.11/ctypes/__init__.py", line 376, in __init__
    self._handle = _dlopen(self._name, mode)
                   ^^^^^^^^^^^^^^^^^^^^^^^^^
OSError: dlopen(/Users/doron/Library/Application Support/pipx/venvs/rpcclient/lib/python3.11/site-packages/capstone/lib/libcapstone.dylib, 0x0006): tried: '/Users/doron/Library/Application Support/pipx/venvs/rpcclient/lib/python3.11/site-packages/capstone/lib/libcapstone.dylib' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64e' or 'arm64')), '/System/Volumes/Preboot/Cryptexes/OS/Users/doron/Library/Application Support/pipx/venvs/rpcclient/lib/python3.11/site-packages/capstone/lib/libcapstone.dylib' (no such file), '/Users/doron/Library/Application Support/pipx/venvs/rpcclient/lib/python3.11/site-packages/capstone/lib/libcapstone.dylib' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64e' or 'arm64'))

[doronz88]

Upon closer inspection, looks like the github action deploys the correct artifacts:
https://github.com/capstone-engine/capstone/actions/runs/10439642736

After downloading you can see:

doron@MacBookPro ~/dev/rpc-project/src/rpcserver master @ file '/Users/doron/Downloads/artifacts-macos-latest/capstone-5.0.2-py3-none-macosx_11_0_arm64.whl/capstone/lib/libcapston
e.dylib'
/Users/doron/Downloads/artifacts-macos-latest/capstone-5.0.2-py3-none-macosx_11_0_arm64.whl/capstone/lib/libcapstone.dylib: Mach-O 64-bit dynamically linked shared library arm64

However, when downloading from PyPi (https://pypi.org/project/capstone/#files) you get the intel binary instead:

doron@MacBookPro ~/dev/rpc-project/src/rpcserver master @ file '/Users/doron/Downloads/capstone-5.0.2-py3-none-macosx_11_0_arm64 (1).whl/capstone/lib/libcapstone.dylib'
/Users/doron/Downloads/capstone-5.0.2-py3-none-macosx_11_0_arm64 (1).whl/capstone/lib/libcapstone.dylib: Mach-O 64-bit dynamically linked shared library x86_64

[doronz88]

When comparing the your python-release action to my own, I noticed I use the following:

https://github.com/doronz88/pytun-pmd3/blob/cd5f68a25232aa5a2ce07435a5d5effa37be3fb7/.github/workflows/pypi-build-publish.yml#L52-L66C11

Note the: merge-multiple: true.
I think this might be the root cause to make the deploy to PyPi be wrong

[XVilka]

Probably could be fixed in #2444 by @Rot127 while it's not yet merged.

[doronz88]

I still thinks its missing the merge-multiple: true in that PR

[Rot127]

@doronz88 Can you comment in the PR? I am not sure what you mean. Because the artifacts have distinct names and should download all of them. But I currently testing it in my repo

[doronz88]

I think the issue should only be closed after its tested via pypi upload since the issue is with the pypi upload specifically.
Meanwhile, the latest pypi remains broken.