On Sat, Oct 16, 2010 at 8:08 PM, Friedrich Romstedt <friedrichromst...@gmail.com> wrote: > 2010/10/16 Ralf Gommers <ralf.gomm...@googlemail.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 >> following: >> "numpy-%s-py%s-python.org-macosx%s.dmg" % (fullversion, pyver, osxver) >> http://github.com/rgommers/numpy/commit/2b1eb79a63cba4 > > 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-10.3 > /Library/Frameworks/Python.framework/2.7-10.5 > /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?
Better than anything I came up with. In the release script we can simply copy over the whole tree before each 2.7 build. > >> 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 > libraries)." (http://article.gmane.org/gmane.comp.python.apple/17182) > > Who knows details about this? Russell asked a while ago if the 2.7 numpy dmg on SF (built against 10.5 python installer) worked for both 10.3 and 10.5 installers from python.org. I checked on my own computer that that was the case, and we got zero bug reports about this - so my answer was yes. I think it's supposed to work for us, but apparently not if you use static libraries like MPL does. Cheers, Ralf _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
