[Numpy-discussion] OS X installers - naming scheme and 2.7 annoyance
Sat Oct 16 07:08:55 CDT 2010
2010/10/16 Ralf Gommers <email@example.com>:
> 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
> "numpy-%s-py%s-python.org-macosx%s.dmg" % (fullversion, pyver, osxver)
There is a correspondence between the macosx version and the arches.
But nevertheless, it's not an equivalence, and the macosxXXX also
implies other libraries which are available and may be linked in (like
Tk as mentioned by Russel on
http://article.gmane.org/gmane.comp.python.apple/17182). Since we'll
provide only those -macosxXXX which python.org does provide, from my
point of view, your suggestion is the best option, if not even perfect
> 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/.
(2) is a bit hacky to me.
> 3) Have only the 10.5 py27 installed, create the 10.3 numpy installer
> by specifying all CFLAGS/LDFLAGS in the paver script.
We may run into the same troube as in "crosscompiling" on 10.6, or not?
> I'm not liking any of those options much. Anyone have a better idea?
4) Installing, and moving the Framework directory, this is what I'll
do when building the dmgs (Vincent started soon ago):
/Library/Frameworks/Python.framework/2.7 -> 2.7-XXX
it should be transparent to any PATH settings etc., and is easy to switch.
Opinions about this?
> 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.
He (Russell) say's that:
"The numpy folks apparently were able to make a single binary
installer that works everywhere with both versions of Python 2.7. I'm
not sure how they managed that, but perhaps numpy doesn't require
bringing in any static libraries (if it uses the built in numeric
Who knows details about this?
More information about the NumPy-Discussion