Open sampotter opened 4 years ago
@sampotter Thanks for reporting this bug. We will look into it.
@da-wad Do you have any thoughts on this?
Hi Sam. Thanks for including the full log, it's definitely helpful. What it indicates is that when you attempt to pip install a binary distribution of zfpy none of the available wheels' tags (see: https://www.python.org/dev/peps/pep-0425/) match your system, and it defaults to the source distribution (which is actually just a package description rather than ZFP source). I cannot claim familiarity with MSYS2, however I do know that C extensions to Python (such as zfpy) need to be compiled with the same compiler as Python itself for ABI compatibility. I suggest we look into whether this has been solved before, and if so how. To do so could you tell us what the value for "Tag" is in the file site-packages\numpy-1.x.x.dist-info\WHEEL when you pip install numpy?
In the meantime you could try using pyzfp, this provides similar functionality but requires a C compiler for installation.
Thanks for the helpful explanation and pyzfp recommendation. This anticipates another problem that was going to come up later: namely, zfpy doesn't expose zfp's parallel compression. ;-)
MSYS2 uses the same package manager as Arch Linux, "pacman", which allows one to install Python packages using it instead of pip. This is "recommended"---I'm not exactly sure why. At any rate, on this system, I went this route instead of the usual conda or virtualenv + pip combination.
Now, when I go looking for numpy's .dist-info directory in site-packages, I instead find an .egg-info. I'm not a Python packaging expert (but I do need to pick it up, so don't hold back), but I understand this means that numpy was packaged as an Egg. Since I installed it using pacman, and since everything else in site-packages has an .egg-info, I'm assuming that Python packages available via pacman come as Eggs.
For what it's worth, I went ahead and installed Anaconda just now on this system and had no trouble installing zfpy from conda-forge. Presumably pyzfp will also be easy to install.
It seems like the problem I ran into may be fairly esoteric and related to the way MSYS2's Python pacman packages are set up. I'm happy to help debug this, but understand if it's not a very high priority!
I'm using MSYS2 and trying to install zfpy from the MinGW 64-bit console, using Python3, and pip installed from the
mingw-w64-x86_64-python-pip
package.To recreate this, one should be able to:
pacman -Sy mingw-w64-x86_64-python mingw-w64-x86_64-python-pip
pip install zfpy
Here's the output with failure message:
Here's the full log file (although I'm not sure it's particular helpful):
Happy to try to help debug this.