Work on #418 revealed there was no available CMake wheel for pypy.
Current status
There is currently one CMake wheel per platform and per python version. For example:
cmake-3.13.3-cp27-cp27m-manylinux1_i686.whl
[...]
cmake-3.13.3-cp27-cp27mu-manylinux1_x86_64.whl
[...]
cmake-3.13.3-cp34-cp34m-macosx_10_6_x86_64.whl
[...]
cmake-3.13.3-cp36-cp36m-win_amd64.whl
[...]
Since there are no wheel with a python tag including pypy or pypy3, trying to run pip install cmake from a pypy interpreter fails.
Toward more generic wheel
Since the CMake wheels (as well as ninja wheels) do not depend on Python C-API, @njsmith suggested in pypa/manylinux#273 (comment) that we should instead distribute less wheels by using the following convention:
cmake-X.Y.Z-py2.py3-none-manylinux2010_x86_64.whl
cmake-X.Y.Z-py2.py3-none-macosx_10_6_x86_64.whl
cmake-X.Y.Z-py2.py3-none-win_amd64.whl
This is a great idea and would reduce the number of wheels we have to build. That said, we would have to setup testing for all python version.
Reference:
Work on #418 revealed there was no available CMake wheel for pypy.
Current status
There is currently one CMake wheel per platform and per python version. For example:
Since there are no wheel with a
python tagincludingpypyorpypy3, trying to runpip install cmakefrom a pypy interpreter fails.Toward more generic wheel
Since the CMake wheels (as well as ninja wheels) do not depend on Python C-API, @njsmith suggested in pypa/manylinux#273 (comment) that we should instead distribute less wheels by using the following convention:
This is a great idea and would reduce the number of wheels we have to build. That said, we would have to setup testing for all python version.
Reference:
{distribution}-{version}(-{build tag})?-{python tag}-{abi tag}-{platform tag}.whl