Closed hickford closed 8 years ago
Came here to report the same issue. I agree with hickford, it seems misleading to show numpy as supporting wheels.
Thanks for the report. I think this is in some ways the flipside of #2.
Given that my other issue about this has just been closed, I reiterate what I said here:
It seems a bit odd to me that a package is marked green as soon as wheels for a single platform are available on PyPi. It gives the impression that it is a good idea to rely on PIP and PyPi to take care of dependencies when this is clearly not the case.
I can see that having more packages green is good advertisement for wheels, but I am not sure if having false greens on the list is the way to go.
Thanks for moving your comment to here, @fladd.
We used to display packages without universal wheels as orange, but that did not go down well and got removed accordingly.
As mentioned in #2, I plan to "indicate exactly what architectures and platforms have been made available as a wheel binary", but this will still mean that packages with platform specific wheels will be shown as green. Hopefully this will be a more useful for everyone.
Hi @meshy,
actually, I don't think the problem here is universal vs. binary wheels.
Given the current situation in which binary wheels are only possible for Windows and OS X, I think what should be green is pretty straight forward:
The project has either (a) a universal wheel, or, (b) to BOTH, Windows and OS X binary wheels.
Taking pillow
as an example, there seem to be many more permutations than that.
Not sure what you mean. With respect to wheels, I see Windows (32 and 64bit) and OS X (32 and 64bit) on the Pillow page.
I mean that it's not just OS that matters when building platform specific wheels, but also processor architecture (which could also include ARM
if I am not mistaken), and python version. There are several dimensions to consider, and it's hard to ensure all bases have been covered to the satisfaction of all.
Thanks for your answer. Yes, architectures indeed have to be considered.
"There are several dimensions to consider, and it's hard to ensure all bases have been covered to the satisfaction of all"
And your conclusion from this is that any single criterium suffices then, instead of them all. I understand that. The statistics hence show the set of packages for which each package has at least one wheel for some platform.
What I am trying to say is that I personally do not find this information particularly useful. I would rather like to get an idea of which packages fully support wheels, so I can rely on this information to decide whether my own package can go wheels. That is, if all my dependencies are available via PIP. If a package was green I could then infer that pip install thatpackage
to work on all platforms the author of that package is targeting. Right now, I can only infer that it might work (which I kind of knew before :-) ).
To me, PIP and its automatic repository search and dependency management is the main benefit of wheels. Given that Linux distros have already solved this problem sufficiently, I further see wheels as a solution for Windows and OS X only.
What I am trying to say is that I personally do not find this information particularly useful.
I agree. That's why I originally made non-universal wheels orange. The current situation where "any single criterium suffices" frustrates me too. As a Linux user, while I cannot use platform specific wheels, the others are of great use, and I also would prefer to be able to use this resource to know if I will be able to install a package with a wheel.
I do not agree that wheels are of primary use to OS X and Windows. My package manager suffices for globally installing python packages, but when it comes to virtual environments (which I require every day for working on projects with differing/conflicting requirements) it's useless. With wheels, I am able to install projects in a fraction of the time that I otherwise could.
I would very much like to display more data, but it is my opinion that displaying fewer than all three of the significant dimensions (OS, python version, architecture) would also be misleading as, like now, users of the site would not get the full picture. I am struggling to find a nice way to display it.
Perhaps I could put the data on an overlay, rather than on the button itself; perhaps there is something that can be done with icons; or perhaps there is a colour scheme that would be less offensive to the people in #29; perhaps a combination of all three. None of these seem ideal to me.
I just did want to report the same issue as well. Reading the above comments I see that it is impossible to find a correct solution to this. However does is necessarily have to be complete? I would suggest to leave the green as it is which means, that if there are any wheels, it is marked green. Furthermore you could add a windows logo if there is ANY windows related wheel and furthermore add an apple if there are ANY osx wheels. This is not a complete solution either but seems to be closer...
Closing this since Numpy now has wheels for Windows and Linux.
Right now, numpy is shown green on http://pythonwheels.com/ . Is that right? It fails one of the criteria:
If you try
pip install numpy
on an out-the-box Python Windows installation, you get the infamously unhelpful error message "Unable to find vcvarsall.bat". This turns out to be because Numpy has wheels only for Mac, not for Windows. https://pypi.python.org/pypi/numpyI'd argue that Numpy shouldn't be shown green until it installs easily on Windows. Out of all the advantages of wheels, easy compilerless installation is perhaps the most important to end users.