> On Feb 23, 2017, at 6:49 AM, Nathaniel Smith <n...@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. — Donald Stufft
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig