meshy
commented
10 years ago Hi @ncoghlan, I'm glad you're finding the site useful. Thank-you for the feedback.
I think you're right that the current colour scheme seems to put undue pressure on package maintainers. While wheels are a fantastic addition to the python ecosystem, I do not like to think that I am making people feel that they are somehow "doing it wrong" just because they're "only" using sdist, and agree that a change of colour would be wise. Also, removing the colour red well solves the accessibility concerns that were raised in #5.
I would like to implement #2, but there are a lot of variables, and I'm not sure that I could come up with a definitive list of factors. Instead, I think it may be better to explicitly state exactly which platforms and architectures have been made available as wheels. Ultimately, this alternative leaves the visitor most informed. Until that has been implemented, it seems more than acceptable to me to mark all packages with wheels as green. Kindly, it seems that @Ian-Foote has already implemented this, and many other improvements in #32.
I understand that to indicate that a project will not be going to python 3 any time soon, one can add 'Programming Language :: Python :: 2 :: Only' to the trove classifiers in setup.py, but I am not aware of a similar specification regarding distribution. Admittedly, I have not looked into this very far. If there is a way of so indicating, I would be very interested.
I have just merged @Ian-Foote's #32, so I hope you don't mind if I close this issue.
Thank-you once again, Charlie.
dstufft
Firstly, thanks for creating the site - it's very useful to have as a progress reporting tool when it comes to providing a "wheel enabled" installation experience for new Python users.
However, there are currently quite a few valid reasons that projects can't publish wheels yet, and these sometimes aren't within the scope of the project themselves to fix. Unfortunately, all such projects show up as red on pythonwheels.com, which does a disservice to the volunteers and other contributors that provide those packages for free download.
A couple of small tweaks would allow the site to retain it's existing usefulness as a progress indicator towards providing a simple starting experience for beginners (without requiring them to install a C compiler), while avoiding the creation of undue pressure on project maintainers to start publishing wheels when the format may not quite be ready for them yet.
The main suggested change would be to use grey rather than red for projects that don't publish wheel files yet - that reduces the connotations of "no wheel file is bad", when at this stage of things, there are plenty of good reasons not to publish wheel files (although it's better to publish them if it is easy to do so).
As discussed in issue #2, there should be a way to get a project with platform and architecture specific wheels to green. For example, binary wheels for Windows and Mac OS X for at least Python 2.7 and 3.3 on x86_64.
Finally, it would be good if there was a way to indicate that a project that publishes only an sdist is a pure Python project, and hence installing from source typically isn't a problem (in those cases, installing from a wheel instead just has the benefit of being a little bit faster). Include such projects as orange would be a good thing, and help indicate projects where the pre-built extension support is needed. However, I'm not sure how practical it is to extract that information from the current PyPI APIs - it may need to wait until PyPI is upgrade to the new Warehouse project (cc @dstufft)