cpu-only version requires pyqrack installation?

[weinbe58]

Hello! This might be a misunderstanding of the PyPI docs says about pyqrack-cpu being standalone, but I'm getting an import error:

    from pyqrack import QrackSimulator
../.venv/lib/python3.12/site-packages/pyqrack/__init__.py:6: in <module>
    from .qrack_system import QrackSystem, Qrack
../.venv/lib/python3.12/site-packages/pyqrack/qrack_system/__init__.py:9: in <module>
    Qrack = QrackSystem()
../.venv/lib/python3.12/site-packages/pyqrack/qrack_system/qrack_system.py:59: in __init__
    raise e
../.venv/lib/python3.12/site-packages/pyqrack/qrack_system/qrack_system.py:56: in __init__
    self.qrack_lib = CDLL(shared_lib_path)
../../../../.local/share/uv/python/cpython-3.12.1-macos-aarch64-none/lib/python3.12/ctypes/__init__.py:379: in __init__
    self._handle = _dlopen(self._name, mode)
E   OSError: dlopen(/usr/lib/qrack/libqrack_pinvoke.dylib, 0x0006): tried: '/usr/lib/qrack/libqrack_pinvoke.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/usr/lib/qrack/libqrack_pinvoke.dylib' (no such file), '/usr/lib/qrack/libqrack_pinvoke.dylib' (no such file, not in dyld cache)

this goes away if I install both pyqrack and pyqrack-cpu but then I need OpenCL.

[WrathfulSpatula]

Thanks for the issue ticket! Sorry, I can't immediately reproduce your issue. (See the screen shot.)

I'd love to help you debug, if you need. Actually, looking at where it's trying to load the dylib from, it seems to be in system folders. There are versions of PyQrack that specifically intend to go looking for the shared library in system folders, so we haven't diagnosed your issue fully yet, but be aware that it might be a simple problem with installing the wrong wheel or source distribution.

It looks like you're on a Mac, but what's your operating system (major) version and instruction set? I'll try to test that specific installation.

[WrathfulSpatula]

(The fact that it's looking in system folders might just be a fallback route because there's a problem with the dylib that should be internally bundled. However, source installations specifically require system library installation. Why? Because you're already installing from source, so it's assumed Qrack will be installed from source, or at least in /usr or /usr/local. Otherwise, the Qrack source would have to be bundled with PyQrack, because we can't differentiate operating system and instruction set for source packages.)

[weinbe58]

I'm running Mac ARM processor. Yeah that makes sense. Would it be possible to ship a binary wheel for ARM based Macs?

[WrathfulSpatula]

There are already 2 wheels for ARM-based Macs: MacOS 14 and MacOS 15. There is also an x86_64-based wheel for Mac 13, which is deprecated. Are you on a version of the OS prior to (major) 14? Because it's time to upgrade, and this works on my ARM-based Mac 15 system. (We'll still get this working for you, though.)

[WrathfulSpatula]

Ah! I know exactly what the issue is!

Mac officially "deprecated" OpenCL, years ago. (This might as well have been a joke, if you ask me: it's still in Macs, and nobody is going to dual-implement in their "Metal" API, for something like this. DirectX tried this over a decade ago, trying to kill the open standard, and Microsoft lost that battle, already.)

Hence, pyqrack wheels (rather than pyqrack-cpu) don't have accelerator support on ARM-based Mac. You shouldn't need to install OpenCL. pyqrack is the package you want.

Are you finding you need to install OpenCL? Because, that isn't necessary on my ARM-based Mac 15 system.

[WrathfulSpatula]

If you have a CUDA accelerator, by the way, another option is pyqrack-cuda. It's slow to install, because I can't know your CUDA architecture based on wheel platform tag, but this has to be known at compile time, so that wheel always builds from source. It should work, though, if you actually have a CUDA accelerator. (It should not be necessary to separately install the Qrack library on your system, in that case: the pyqrack-cuda package pulls a specifically-tagged commit from the Qrack repository and builds that one in the PyPi source installation process.)

[WrathfulSpatula]

(By the way, it's clear you actually read the README, but that's likely what confused you in the first place, so sorry about that. Most users seem to just pip install pyqrack and never think about it again, so long as it works at that point, which is why pyqrack Mac wheels for ARM are designated this way. Most users even in our own organization seem to be on ARM Mac, and that's basically how they went about installation for our own project dependence on pyqrack. I'm updating the README right now to clarify this, so thank you.)

[weinbe58]

Are you finding you need to install OpenCL? Because, that isn't necessary on my ARM-based Mac 15 system.

actually I haven't had any issues with OpenCL on my laptop but @Roger-lou has mentioned some issues with OpenCL, not sure if he has an Arm based Macbook or not though.

I think the solution is we're just gonna add both pyqrack-qpu pyqrack and pyqrack-cuda as separate dependencies on our projects so people can install whichever one they want.

[WrathfulSpatula]

I think the solution is we're just gonna add both pyqrack-qpu pyqrack and pyqrack-cuda as separate dependencies on our projects so people can install whichever one they want.

If it would help you for me to change the packaging system for these three different versions of PyQrack, I would consider changing our system. I know that all three versions could be under the same package and controlled by an additional option on pip installation, but I thought it would be more confusing for many users. If you find things would be much simpler for your downstream project if we managed these versions a different way, please feel free to propose a change to PyQrack!

[weinbe58]

Thanks! that would be great! I won't be able to work on this for a bit but if we get more demand I will propose working on this