Packages with C extensions can never go green

[meshy]

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.

[minrk]

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

[vsajip]

this will hopefully be relaxed for OS X soon, but will probably never be allowed for Linux

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

[minrk]

Just curious - why never?

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.

Why isn't the variability of OS X builds also problematic, with framework vs. non-framework, gcc vs. clang, MacPorts vs. Homebrew etc.?

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:

1. (opinionated) it should really only be the responsibility of binaries on PyPI to work on Python.org Python (at least) and Python.org + System Python (at most). Any binaries that work on other Pythons are gravy.
2. (practical) These differences typically do not actually cause an incompatibility.

[meshy]

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.

[chrish42]

Now that wheel uploads are allowed for Windows, Mac and Linux, it might be nice to revisit this...

[kevin-brown]

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.

[LilyFirefly]

Go for it. I think the hard bit isn't the code - it's getting the UI right.

[webknjaz]

JFTR

Packages with C extensions can never go green

is a bit misleading. Some projects may contain pure-python fallbacks. And so in the aiohttp land we have any-none wheels in addition to platform specific ones.