[Numpy-discussion] Any plans for windows 64-bit installer for 1.7?

[Chris Barker - NOAA Federal]

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 at noaa.gov