Closed matthiaskoenig closed 7 months ago
My guess is that Arch is telling you there will be problems if you install with pip, and you shouldn't do it. If so, getting the pip wheels directly won't help, as the underlying problems will still exist.
Arch says, there is no package on pip, but downloading the wheel manually and installing it works without issues. I.e. roadrunner works via wheels on Arch, but cannot be installed via pip. So people on Arch (or other linux distributions not supported via pip) just have to know about the wheels. This is just a documentation issue.
I've just noticed that Miniconda provide distributions for Linux-x64 and Linux-aarchx64. Do you think if we were to switch to the Linux-aarchx64 version this problem would be resolved? Or perhaps we'd just cause the same problem but on a different subset of linux machines.
My second thought on this regarding the PEP425 compatibility tag that we are using. We manually rename our linux builds to manylinux2014, which is what they are built. Pip won't accept wheels named simply with "linux" anymore. I wonder if there is a different tag that would be accepted for a wider variety of linux platforms?
Does Arch still behave like this? Does it require some other tag in order to install from pip?
Closing this. Is solved.
For some linux distributions/kernels the python pip packages via pypi are not working (i.e. they are not recognized as install candidates). E.g. on Arch libroadrunner cannot be installed via pip. The workaround/solution is to download the build artifacts from the Azure pipeline and install them with
pip
. These wheels are available from the releases, e.g., https://github.com/sys-bio/roadrunner/releases/tag/v2.2.0These wheels should be mentioned in the roadrunner documentation with a sentence about the installation. I.e. something along the line of: