On Tue, May 19, 2015 at 11:10 AM, Paul Moore <p.f.moore@gmail.com> wrote:
to be the same. I suppose I could deliver the static libs themselves, along with the headers, etc, but that does get ugly.
Hmm, that seems to me to be something of a non-goal. If you publish wheels, 99.999% of people should never need to build your software.
I'm not so sure -- with a nice mature package, sure. But with something under active development, having a low barrier to entry to running the latest code is really helpful. I suppose I could use a CI system to push a new version of the binary wheel with every update - maybe that is the way to go. I'm 100% in favour of repeatable, automated builds - absolutely
But we don't really need a standard infrastructure for them, you write a "setup_build_environment.py" script that ships with your project, run it once, and then run python setup.py bdist_wheel. If your build dependencies are simple, "setup_build_environment.py" could be short (or even non-existent!) or if not it could be many hundreds of lines of code. But it's specific to your project.
This entire conversation is about when the build dependencies are NOT simple :-). And while it may be project specific, commonly used libs are not project specific, and they are where the time and pain are. So some shared infrastructure would be nice. And maybe all that needs to be is a gitHub project with build scripts. But I had little luck in getting any traction that way. That is, until we had Anaconda, conda and binstar --- an infrastructure that provides a way for folks to collaborate on this kind of ugly package building effort. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov