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