Actually, since they're wheels, they´re already built, so installing them will work perfectly. Trying to use them is what's going to fail with a message like:

I do think Nate's proposal is a step forward[1], since being unable to use the package because a runtime dependency is not installed is no more of a problem than being unable to install a source package because a build dependency is not installed. And the package documentation could always specify which system packages are needed for using the wheel.

If anything, the error message tends to be smaller, whereas a missing .h from a missing development package usually causes a huge stream of error messages on build, only the first of which is actually relevant. Then again, an import error could happen anywhere in the middle of running the software, so in some cases the error might not be obvious at first.

My proposal (that wheels should specify the system file dependencies in terms of abstract locations) would allow pip to provide a much more user-friendly information about the missing file, in the earliest possible moment, allowing for the user to hunt (or compile) the system package at the same moment as he's installing the python package.

This information is readily derived during the build process, making it's inclusion in the wheel info straightforward.

But I don't think my proposal should block acceptance of Nate's.

[1] As long as the acceptance of the over-specified wheels is a strictly opt-in process. Some linux folks don't like running code they haven't compiled.

Regards,

Leo