<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Aug 14, 2015 at 9:17 AM, Steve Dower <span dir="ltr"><<a href="mailto:steve.dower@python.org" target="_blank">steve.dower@python.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I actually like two ideas for Windows (not clear to me how well they apply on other platforms),</blockquote><div><br></div><div>I think this same approach should be used for OS-X, not sure about Linux -- on LInux, you normally have "normal" ways to get libs.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> both of which have been mentioned in the past:<br>
<br>
* PyPI packages that are *very* thin wrappers around a shared library<br>
<br>
For example, maybe "libpng" shows up on PyPI, and packages can then depend on it. It takes some care on the part of the publisher to maintain version-to-version compatibility (or maybe wheel/<a href="http://setup.py/.cfg" rel="noreferrer" target="_blank">setup.py/.cfg</a> grows a way to define vendored dependencies?) but this should be possible today.<br></blockquote><div><br></div><div>excep that AFAICT, we have no way to describe wheel (or platform) dependent dependencies:</div><div><br></div><div>i.e "this particular binary wheel, for Windows depends on the libPNG version x.y wheel"</div><div><br></div><div>Though you could probably fairly easily path that dependency into the wheel itself.</div><div><br></div><div>But ideally, we would have a semi-standard place to put such stuff, and then the source package would depend on libPNG being there at build time, too, but only on Windows. (or maybe only on OS-X, or both, but not Linux, or...)</div><div><br></div><div>Or just go with conda :-) -- conda packages depend on other conda packages -- not on other projects (I.e. not source, etc). And yuo can do platform dependent configuration, like dependencies.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">* "Packages" that contain shared sources<br>
<br>
One big problem on Windows is there's no standard place to put library sources, so build tools can't find them. If a package declared "build requires libpng.x.y source" then there could be tarballs "somewhere" (or even links to public version control) that have that version of the source, and the build tools can add the path references to include it.<br></blockquote><div><br></div><div>That would be the source equivalent of the above, and yes, I like that idea -- but again, you need a way to express platform-dependent dependencies. Though given that setup.py is python code, that's not too hard.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">There was discussion about an "incompatible_with" metadata item at one point. Could numpy include {incompatible_with: "scipy<x.y"} in such a release? Or would that not be possible.<br></blockquote><div><br></div><div>circular dependency hell! scipy depends on numpy, not teh other way around -- so it needs to be clear which version of numpy a given version of scipy depends on.</div><div><br></div><div>-CHB</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>