[Numpy-discussion] OS X installers - naming scheme and 2.7 annoyance

[Ralf Gommers]

Hi all,

With there being two different installers for Python 2.7 on python.org
(10.3+ has ppc/i386, 10.5+ has ppc/i386/x86_64) a change to the naming
scheme is needed for the numpy binaries. That's assuming we provide
two corresponding installers with the same arches. I propose the
following:
"numpy-%s-py%s-python.org-macosx%s.dmg" % (fullversion, pyver, osxver)
http://github.com/rgommers/numpy/commit/2b1eb79a63cba4

These two 2.7 versions are fairly annoying by the way - only one of
them can live in /Library/Frameworks. Here are the options I see to
fix this:
1) Manually reinstall the desired version, then build the installer against it.
2) Have two clearly named virtualenvs for them and build against those
executables without activating the virtualenvs. Then change the
hardcoded python executable path in the generated Info.plist files
under tools/numpy-macosx-installer/content/.
3) Have only the 10.5 py27 installed, create the 10.3 numpy installer
by specifying all CFLAGS/LDFLAGS in the paver script.

I'm not liking any of those options much. Anyone have a better idea?

The python.org offering may change again in the near future by the
way. Excerpt from an email by Ronald Oussoren on the pythonmac list:
"The consensus at the [europython] summit was to replace the
macosx10.5 installer (ppc, x86, x86_64) by a macosx10.6 (x86, x86_64)
installer for future releases. That enables linking with Tk 8.5 and
that would solve a number of issues other than being available in
64-bit code. Users of OSX 10.5 (or earlier) can still use the
macosx10.3 installer, that would stay the same. The only difference
for OSX 10.5 users is that they cannot use 64-bit code without
building their own binaries."

Finally, this post is related:
http://article.gmane.org/gmane.comp.python.apple/17182, will be
relevant for numpy too.

Ralf