<div dir="ltr">I'm not sure if I understand what Nathaniel is getting at, but...<br><div class="gmail_extra"><br><div class="gmail_quote"><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"><span class="">> As the very simplest example, every package that uses the numpy C API<br>
> gets a runtime dependency on "numpy >= [whatever version happened to<br>
> be installed on the *build* machine]".</span></blockquote><div> </div><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">From my point of view, it's not a source distribution or a binary<br>
distribution that depends on something (numpy or whatever) - it's the<br>
*project*. If project foo needs numpy to work, it depends on numpy. If<br>
it depends on features in numpy 1.9, it depends on numpy>=1.9.<br></blockquote><div><br></div><div>Here is the gap (I'm a bit confused about what a "project" is -- so I"ll use the term "package", meaning a python package).</div><div><br></div><div>A given package might depend on numpy, as you say, and it may work with all numpy versions 1.6 to 1.9. Fine, so we specify that in install_requires. And this shodl be the dependency in the sdist, too. If the package is pur python, this is fine and done.</div><div><br></div><div>But if the package has some extensions code that used the numpy C API ( a very common occurrence), then when it is built, it will only work (reliably) with the version of numpy it was built with.</div><div><br></div><div>So the project itself, and the sdist depend on numpy >=1.6, but a build binary wheel depends on numpy == 1.7 (for instance).</div><div><br></div><div>Which requires a binary (wheel) dependency that is somewhat different than the source dependency.</div><div><br></div><div>In a way, this is a lot like a python package that may work fine on py2.7 to py3.5, but a binary wheel is for py3.4 specifically (yes?)</div><div><br></div><div>Note that conda, being developed originally for scipy, has packages like:</div><div><br></div>gsw-3.0.3-np19py27_0.tar.bz2</div><div class="gmail_quote"><br></div><div class="gmail_quote">so this binary depends specifically on py2.7 and numpy1.9</div><div class="gmail_quote"><br></div><div class="gmail_quote">but once you get beyond python_numpy, you cold get a REALLY BIG matrix of possible version combnations!</div><div class="gmail_quote"><br></div><div class="gmail_quote">nevertheless, I think it would be really helpful to have the concept of a binary dependency that is distinct from the "package" dependency. Maybe down to "this wheel depends on this other particular wheel" - not only version, but also wheel specific.</div><div class="gmail_quote"><br></div><div class="gmail_quote">That would open the door to making wheels for binary non-python dependencies like libpng: then other wheels would depend on the libpng wheel, but different wheels built from the same package might have those dependencies handled differently, particularly on different platforms.</div><div class="gmail_quote"><br></div><div class="gmail_quote"><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">I can understand that a binary wheel may need a certain set of<br>
libraries installed - but that's about the platform tags that are part<br>
of the wheel definition, not about dependencies. Platform tags are an<br>
ongoing discussion, and a good example of a partial solution that<br>
needs to be extended, certainly, but they aren't really relevant in<br>
any way that I can see to how the build chain works.<br></blockquote><div><br></div><div>I haven't followed the discussion well, but I really think platform tags are never going to be specific enough to handle these use-cases And these really ARE dependencies, even if they aren't pure-python ones...</div><div><br></div><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">And if my<br>
understanding is correct, I'm against trying to fit that information<br>
into a dependency simply to work around the current limitations of the<br>
platform tag mechanism.<br></blockquote><div><br></div><div>I can't imagine how you could extend platform tags to cover all of this -- but maybe I'm being unimaginative...</div><div><br></div><div>BTW, numpy is nearly unique here -- I can't think of any other package that is a python package with a C API that is widely used -- most other cases are either a python package OR a regular old compiled lib. Which is probably why conda can get away with essentially special casing it.</div><div><br></div><div>-Chris</div><div><br></div></div><div><br></div>-- <br><div class="gmail_signature"><br>Christopher Barker, Ph.D.<br>Oceanographer<br><br>Emergency Response Division<br>NOAA/NOS/OR&R (206) 526-6959 voice<br>7600 Sand Point Way NE (206) 526-6329 fax<br>Seattle, WA 98115 (206) 526-6317 main reception<br><br><a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a></div>
</div></div>