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

Packages with C extensions can never go green #2

Open
meshy opened this issue Nov 12, 2013 · 7 comments
Open

Packages with C extensions can never go green #2

meshy opened this issue Nov 12, 2013 · 7 comments

Comments

@meshy
Copy link
Owner

meshy commented Nov 12, 2013

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
Copy link

minrk commented Nov 15, 2013

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
Copy link

vsajip commented Feb 23, 2014

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
Copy link

minrk commented Feb 23, 2014

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
Copy link
Owner Author

meshy commented Feb 25, 2014

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
Copy link

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

@kevin-brown
Copy link

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
Copy link
Collaborator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants