Okay the patch has been worked over in the bundled fork of setuptools that Tahoe-LAFS uses ("zetuptoolz"), and applying the patch made the build go from red to green on many different platforms and did not introduce a regression from green to red on any builder. It has now gone into Tahoe-LAFS trunk and will be released in Tahoe-LAFS v1.8.1 soon.
I disagree that it should prefer binary over sources in general. Possibly some sort of parameter indicating that it should could be an option, and this could then be used on systems that does not have compilers.
I tend to agree with Lennart, though I have encountered some cases where this issue would bite Windows users - if a binary build is available and the user doesn't have a suitable compiler environment set up, setuptools/distribute would find the later, source-only version, attempt to compile it, and fail, even though it could have succeeded with the binary build that also satisfied the requirements.
I see Zooko's point - distribute does prefer binary builds when they're available as the latest version. It seems reasonable that it could also prefer binary builds when they're not the latest.
I don't think we want to change the status quo at this time, however. Instead, Lennart's suggestion of an option sounds good. Perhaps it could be enabled by either a command-line switch or an environment variable.
Zooko, I believe if the feature were made available as an option, I would have little concern pulling in the change. Furthermore, if we were to find that a majority of users were to be using the option, we would consider making it the default in the future.
Well, we have a specific use case where this behavior is necessary, and I have not yet understood if there are any specific use cases where the opposite behavior is necessary. It isn't only Windows users who don't have a development environment installed -- it is quite common on Linux and Mac as well.
In the Tahoe-LAFS project, we have long ago started using a fork of setuptools/distribute which changes this behavior to the way our users needed. This greatly reduced the frequency of this sort of bug report. (It didn't entirely eliminate this sort of bug report only because there are still some cases where no binary package exists of a sufficient version for the user's platform, which is of course a different problem but with similar symptoms from the user's perspective.) Therefore, we were able to close this ticket:
We also wrote unit tests which simulated the situation (a binary egg of a sufficient version number, for the current platform, plus a source egg of a sufficient and newer version number) and installed those unit tests on our buildbot to confirm that our patch worked on all of our supported platforms. You can find the relevant patches in our trac:
In all honesty, my enthusiasm for contributing patches to Python packaging tools is currently on the wane. Or maybe simply my load of competing work is greater than ever? In any case, while I will certainly help by providing debugging services, patches, answers to questions, or anything else you need if you were to take the initiative of adopting this feature, I'm not likely to keep pushing this feature on my own if your interest is minimal.