
I'm trying to weed out the issues here: 1) what should the binary installer for Windows look like: * bdist_wininst is the obvious choice but apparently has issues with the newer Windows security stuff -- the real solution is for distutils to be fixed/use something else/ etc -- but is there anyone here that has expertise, interest or time to get in and add-to or fix distutils? Do binary eggs solve any of this ? maybe, but pip doesn't support that last I saw, and setuptools easy-install is kind-of sort-of broken. But coming up with the best binary installer tool is orthogonal to the other questions: 2) Should we distribute binaries at all? - No: most people need a whole stack anyway, so they should get all that from the same place: - Enthought - Python(x.y) - Chris Gohlke's repository... - Yes: Some folks just want numpy damn it! Those big ol' distributions are a mess that don't work for everyone. (I'm in that camp.....) But if we distribute binaries, we really should: - distribute them for 32 & 64 bit - Clearly define what the "official" binaries are, so that third-party packagers can build against that. Historically, this has been a huge mess on the Mac, as there are many options for Python itself: Apple's builds, Python,org builds, macports, fink, homebrew, ...... Over the years, we in teh MacPython community have tried hard to establish that the python.org builds are the "official" builds that folks should support with binaries -- this has kind-of, sort-of worked, but I still don't see a better solution. (macports et al aren't really the issue, they aren't based on binaries anyway) On Windows, this has been pretty much a non-issue: MS doesn't provide a build, and the pyton.org builds are well accepted as the default binaries. AFAIU, third party distributions are compatible as well (Active State, Enthought) The parallel here is that we can establish in the scientific python community (that is, folks building packages based on numpy) that the binaries distributed by numpy are the "official" ones that should be supported by third part binaries. If we succeed in that, then folks can get the rest of the stack from any number of sources. the python.org python builds are built with the MS compilers, is there any reason we HAVE to build with a open-source stack? Can you build third party packages against an MS-built binary numpy with open-source compilers? -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