<div dir="ltr">Hi Tres,<br><div class="gmail_extra"><br><div class="gmail_quote">On 21 July 2015 at 00:25, Tres Seaver <span dir="ltr"><<a href="mailto:tseaver@palladion.com" target="_blank">tseaver@palladion.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">[...]<br>
<br>
Even given the "over-specified" platform tags Nick suggests, linux wheels<br>
won't fully work, because the build-time depes won't be satisfiable *by<br>
pip*:  the burden will be on each project to attempt a build and then<br>
spit out an error message trying to indicate the missing system package.<br></blockquote><div><br></div><div>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:</div><div><br></div></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_quote"><div>ImportError: libxslt.so.1: cannot open shared object file: No such file or directory<br></div></div></div></blockquote><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>This information is readily derived during the build process, making it's inclusion in the wheel info straightforward.</div><div><br></div><div>But I don't think my proposal should block acceptance of Nate's.</div><div><br></div><div>[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.</div><div><br></div><div>Regards,</div><div><br></div><div>Leo</div></div></div></div>