On Feb 23, 2017, at 6:49 AM, Nathaniel Smith <njs@pobox.com> wrote:

(Here's an example I've just run into that involves a == dependency on
a public package: I have a library that needs to access some C API
calls on Windows, but not on other platforms. The natural way to do
this is to split out the CFFI code into its own package,
_mylib_windows_helper or whatever, that has zero public interface, and
have mylib v1.2.3 require "_mylib_windows_helper==1.2.3; os_name ==
'nt'". That way I can distribute one pure-Python wheel + one binary
wheel and everything just works. But there's no sense in which this is
an "integrated application" or anything, it's just a single library
that usually ships in one .whl but sometimes ships in 2 .whls.)

((In actual fact I'm currently not building the package this way
because setuptools makes it extremely painful to actually maintain
that setup. Really I need the ability to build two wheels out of a
single source package. Since we don't have that, I'm instead using
CFFI's slow and semi-deprecated ABI mode, which lets me call C
functions from a pure Python package. But what I described above is
really the "right" solution, it's just tooling limitations that make
it painful.))

Another way of handling this is to just publish a universal wheel and a Windows binary wheel. Pip will select the more specific one (the binary one) over the universal wheel when it is available.