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

[Ralf Gommers]

On Sat, Oct 16, 2010 at 8:08 PM, Friedrich Romstedt
<friedrichromstedt at gmail.com> wrote:
> 2010/10/16 Ralf Gommers <ralf.gommers at 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