Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Providing wheels that are incompatible with PEP 513 #28

odashi opened this Issue Dec 17, 2017 · 1 comment


None yet
2 participants
Copy link

odashi commented Dec 17, 2017

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:

@odashi odashi added the question label Dec 17, 2017

@odashi odashi changed the title Providing wheels that are incompatible with PEP513 Providing wheels that are incompatible with PEP 513 Dec 17, 2017

@odashi odashi added the help wanted label Dec 17, 2017


This comment has been minimized.

Copy link

vbkaisetsu commented Dec 18, 2017

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."

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.