Fair enough, I didn't think of compiled wheels :)
And having a clean way to run tests for the provided wheel is indeed an other good point.

On Mon, Mar 30, 2015 at 5:04 PM, Donald Stufft <donald@stufft.io> wrote:

On Mar 30, 2015, at 10:58 AM, Xavier Fernandez <xav.fernandez@gmail.com> wrote:

Wheels without sdists are likely a generally bad idea, downstream
redistributors are not going to like them.

Why do you think that ? Wheels seem way simpler/saner than all the possible things setup.py can do.

Wheels are simpler than a setup.py, because wheels are a binary format and Wheels don’t need to
handle things like build software because it’s already been built. However downstream redistributors
will not accept a Wheel as the source for a package because it is a binary format. It doesn’t matter
if you can unzip it and there is pure python there, it is still a binary format. So if you release only Wheels
you’re essentially saying that downstream redistributors will never package your software (or any
software that depends on it).

A few issues that Wheel only has:

* If your project has a C extension, downstream redistributes need access to the source code not the
  compiled code (as does anyone wanting to use the project on platform you didn’t release for).

* If your project has tests that don’t get installed, they should get shipped as part of the sdist so that
  downstream can run them as part of their packaging activities to ensure they didn’t break anything
  in the test suite. However if you’re installing from Wheel you can’t do that.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA