-
Notifications
You must be signed in to change notification settings - Fork 27
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
Packages with C extensions can never go green #2
Comments
It seems a bit silly that only pure Python packages can be green, when most of the value of wheels is in compiled binaries that can't ever have universal wheels. Don't forget that PyPI explicitly forbids upload of binary wheels for anything but Windows (this will hopefully be relaxed for OS X soon, but will probably never be allowed for Linux). So I would suggest that for packages with binaries, a wheel for Windows Python 2.7 and 3.3 should be sufficient for green (though you could be aggressive and require that people support 3.2, etc). For instance, I have wheels for pyzmq for 32b and 64b Windows Python 2.7 and 3.3 (4 wheels on PyPI), plus universal wheels for OS X 2.7 and 3.3 (on GitHub, because they are forbidden from PyPI). |
Just curious - why never? Why isn't the variability of OS X builds also problematic, with framework vs. non-framework, gcc vs. clang, MacPorts vs. Homebrew etc. ? |
Linux has sensible package managers, and it has generally been the opinion of core Python folks that binary distributions on Linux should be done through apt, yum, etc., rather than bdists on PyPI. The same cannot be said for OS X or Windows.
A similar question: Why isn't the variability on Windows a problem, with differing VC versions, msvc vs mingw, Anaconda vs Python(x,y) vs Canopy etc.? Two answers to this:
|
Orange is now gone (or will be as soon as I re-deploy). Going forward I plan to indicate exactly what architectures and platforms have been made available as a wheel binary. It seems to me that this presents the most data to the visitor without discriminating against packages that have no choice about offering universal wheels. |
Now that wheel uploads are allowed for Windows, Mac and Linux, it might be nice to revisit this... |
Would you be willing to entertain a pull request that adds OS indicators for what operating systems have Wheel packages available for them? This should be fairly easy to detect based on the platform tag. |
Go for it. I think the hard bit isn't the code - it's getting the UI right. |
Anything with C extensions can never go green, because they'll never be able to add a generic wheel. We could define an acceptable combination of OS/Architecture wheels that show that a package is as best distributed as possible given the limitations.
The text was updated successfully, but these errors were encountered: