<div dir="ltr"><div class="gmail_extra">Hi all,<div><br></div><div>Thanks for the lively debate - I sent the message to start the thread and then had a week's vacation - and I appreciate the discussion that took place in the interim. I've encountered all of the problems discussed here, especially the dependencies both with Python and other attempts at package management in distributed heterogeneous systems. For Galaxy's controlled ecosystem we deal with this using static linking (e.g. our psycopg2 egg is statically linked to a version of libpq5 built for the egg), but this is not an ideal solution for a variety of reasons that I doubt I need to explain.</div><div><br></div><div>As for the Python side of things, I certainly agree with the point raised by Leonardo that an ENOENT is probably easier for most to debug than a missing Python.h. For what it's worth, some libraries like PyYAML have a partial solution for this: If libyaml.so.X is not found at runtime, it defaults to a pure Python implementation. This is not ideal, for sure, nor will it be possible for all packages, and it depends on the package author to implement a pure Python version, but it does avoid an outright runtime failure.</div><div><br></div><div><div>I hope - and I think that Nick is advocating for this - that incremental improvements can be made, rather than what's been the case so far: identifying the myriad of problems and the shortcomings of the packaging format(s), only to stall on making progress towards a solution.</div></div><div><br></div><div>As to the comments regarding our needs being met today with a wheelhouse, while this is partially true (e.g. we've got our own PyPI up at <a href="https://wheels.galaxyproject.org">https://wheels.galaxyproject.org</a>), we still need to settle on an overspecified tag standard and fix SOABI support in Python 2.x in order to avoid having to ship a modified wheel/pip with Galaxy.</div><div><br></div><div>Is there any specific direction the Distutils-SIG would like me to take to continue this work?</div><div><br></div><div>Thanks,</div><div>--nate</div><div class="gmail_quote"><br></div><div class="gmail_quote">On Mon, Jul 27, 2015 at 10:19 AM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 21 July 2015 at 04:37, Paul Moore <<a href="mailto:p.f.moore@gmail.com" target="_blank">p.f.moore@gmail.com</a>> wrote:<br>
> On 20 July 2015 at 18:37, Chris Barker <<a href="mailto:chris.barker@noaa.gov" target="_blank">chris.barker@noaa.gov</a>> wrote:<br>
>> sure -- but isn't that use-case already supported by wheel -- define your<br>
>> own wheelhouse that has the ABI you know you need, and point pip to it.<br>
><br>
> I presume the issue is wanting to have a single shared wheelhouse for<br>
> a (presumably limited) number of platforms. So being able to specify a<br>
> (completely arbitrary) local platform name at build and install time<br>
> sounds like a viable option.<br>
<br>
</span>While supporting multiple distros in a single repo is indeed one use<br>
case (and the one that needs to be solved to allow distribution via<br>
PyPI), the problem I'm interested in isn't the "success case" where a<br>
precompiled Linux wheel stays nicely confined to the specific<br>
environment it was built to target, but rather the failure mode where<br>
a file "escapes".<br>
<br>
Currently, there's nothing in a built Linux wheel file to indicate its<br>
*intended* target environment, which makes debugging ABI mismatches<br>
incredibly difficult. By contrast, if the wheel filename says "Fedora<br>
22" and you're trying to run it on "Ubuntu 14.04" and getting a<br>
segfault, you have a pretty good hint as to the likely cause of your<br>
problem.<br>
<br>
Cheers,<br>
Nick.<br>
<span><font color="#888888"><br>
--<br>
Nick Coghlan | <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a> | Brisbane, Australia<br>
</font></span><div><div>_______________________________________________<br>
Distutils-SIG maillist - <a href="mailto:Distutils-SIG@python.org" target="_blank">Distutils-SIG@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/distutils-sig" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/distutils-sig</a><br>
</div></div></blockquote></div><br></div></div>