Providing wheels that are incompatible with PEP 513

[odashi]

Wheel packages hosted on PyPI basically should support PEP 513 standard (namely, manylinux1 tag) to follow most Linux distributions. But usually, because most neural network libraries are used together with some unofficial computing backends such as CUDA, strictly supporting PEP 513 does not fit this kind of situation.
We'd like to have some discussion that what kind of positions about this problem should the primitiv-python library stand on.

Positions of other libraries:

• TensorFlow does support explicitly only limited subsets of distributions, but PyPI repository provides them with tag manylinux1 for some reason (Provide manylinux1 wheels on PyPI tensorflow/tensorflow#5033, Wheels on PyPI violate manylinux1 specification / PEP513 tensorflow/tensorflow#8802).
• DyNet also provides manylinux1 wheels, but probably they do not include GPU backends for now (Precompiled wheels with GPU clab/dynet#855).
• PyTorch does not provide any wheels, and even any sources hosted on PyPI (rebuild pip wheels with manylinux pytorch/pytorch#566).

[vbkaisetsu]

To benefit from PyPI and pip framework, I think the best method is providing a source package.

PyPI and pip are maintained on the assumption that we follow manylinux1 policy. If we provide a binary package ignoring the policy, unexpected problem can happen.
On the other hand, if we provide a binary package without GPU support, many users will download a source package from GitHub to use GPU. We will lost everything.

PEP 8:

Comments that contradict the code are worse than no comments.

In this situation, "incomplete wheels are worse than no wheels."