search

meshy / pythonwheels

Adoption analysis of Python Wheels: https://pythonwheels.com/
BSD 2-Clause "Simplified" License
102 stars 26 forks source link

Packages with C extensions can never go green #2

Open meshy opened 10 years ago

meshy commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 8 years ago

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

kevin-brown commented 8 years ago

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.

LilyFoote commented 8 years ago

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