[Numpy-discussion] OS X installers - naming scheme and 2.7 annoyance
Ralf Gommers
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
_______________________________________________
NumPy-Discussion mailing list
NumPy-Di...@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Friedrich Romstedt
> 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?
> 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?
Friedrich
Ralf Gommers
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
Vincent Davis
Just to be clear. If we are building a 10.5 numpy py27 release we
should be building it on Python
"32-bit Mac Installer disk image (2.7) for OS X 10.3 and later (sig)".
Is this correct or the proposal?
Vincent
>
> Finally, this post is related:
> http://article.gmane.org/gmane.comp.python.apple/17182, will be
> relevant for numpy too.
>
> Ralf
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Di...@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
--
Thanks
Vincent Davis
720-301-3003
Ralf Gommers
No, numpy-1.5.1-py2.7-python.org-macosx10.5.dmg would be built against
the version in XX-macosx10.5 installer from python.org, and
numpy-...macosx10.3.dmg against XX-macosx10.3 installer.