On Sat, Nov 7, 2015 at 4:03 PM, Paul Moore
I see building a wheel as a release activity. As such, it should produce a reproducible result, and so should not be affected by arbitrary state in the development directory. I don't know whether you consider "ensuring the wheels aren't wrong" as aimed at developers or at end users, it seems to me that both parties benefit.
Personally, I'm deeply uncomfortable about *ever* encountering, or producing (as a developer) sdists or wheels with the same version number but functional differences. I am OK with installing a development version (i.e., direct from a development directory into a site-packages, either as -e or as a normal install) where the version number doesn't change even though the code does, but for me the act of producing release artifacts (wheels and sdists) should freeze the version number.
The problem with this is that we want to get rid of "direct installs" entirely, and move to doing wheel-based installs always -- direct installs require that every build system has to know about every possible install configuration, and it's just not viable. I think the way to approach this is to assume that 'pip install <whatever>' will always 100% of the time involve a wheel; the distinction is that sometimes that wheel is treated as a reliable artifact that can be cached etc., and that sometimes it's treated as a temporary intermediate format that's immediately discarded. (As a separate point I do think it would be good to encourage people to use + versions like 1.2+dev for VCS trees, or better yet 1.2+dev.<hash>, to emphasize that these are not real reliable version numbers. (Recall that PEP 440 defines + as defining a "local version" that's explicitly somewhat unreliable, not allowed on index servers, etc.) But even pip itself doesn't follow this rule right now so for the foreseeable future we'll have to assume that source directories have unreliable version numbers.) -n -- Nathaniel J. Smith -- http://vorpus.org