<p dir="ltr">Yes, but how do you know that I compiled against the right version of libc?</p>
<br><div class="gmail_quote"><div dir="ltr">On Fri, Jul 17, 2015, 9:13 PM Chris Barker - NOAA Federal <<a href="mailto:chris.barker@noaa.gov">chris.barker@noaa.gov</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> On Jul 17, 2015, at 1:19 PM, Daniel Holth <<a href="mailto:dholth@gmail.com" target="_blank">dholth@gmail.com</a>> wrote:<br>
><br>
> I've recently packaged SDL2 for Windows as a wheel, without any Python code. It is a conditional dependency "if Windows" for a SDL wrapper.<br>
<br>
Cool, though I still think we need wheel-level deps -- the dependency<br>
is on the particular binary, not the platform. But a good start.<br>
<br>
><br>
> We were talking on this list about adding more categories to wheel, to make it easier to install in abstract locations "confdir", "libdir" etc. probably per GNU convention which would map to /etc, /usr/share, and so forth based on the platform.<br>
<br>
Where would the concrete firs be? I think inside the Python install<br>
I.e. Where everything is managed by python . I don't think I want pip<br>
dumping stuff in /use/local, nevermind /usr. And presumably the goal<br>
is to support virtualenv anyway.<br>
<br>
> Someone needs to write that specification. Propose we forget about Windows for the first revision, so that it is possible to get it done.<br>
<br>
If we want Windows support in the long run -- and we do -- we should<br>
be thinking about it from the start. But if it's going in the<br>
Python-managed dirs, it doesn't have to follow Windows convention ...<br>
<br>
> The real trick is when you have to depend on something that lives outside of your packaging system, for example, it's probably easier to ship qt as a wheel than to ship libc as a wheel.<br>
<br>
Well, we can expect SOME base system! No system can exist without libc....<br>
<br>
-CHB<br>
</blockquote></div>