[Numpy-discussion] Which Python to Use on OSX, Was: 1.1.0 OSX Installer Fails Under 10.5.3?
Wed Jun 4 13:23:54 CDT 2008
On Wed, Jun 4, 2008 at 2:40 AM, Robin <firstname.lastname@example.org> wrote:
> On Wed, Jun 4, 2008 at 9:25 AM, J. Stark <email@example.com> wrote:
>> I see your point, but why not just install a separate NumPy to run
>> with the system Python? That is what I have always done in the past
>> without problems.
> I think the problem is the system python already comes with a (much
> older) cut down version of numpy which you can find in:
> This makes all sorts of problems when installing a new version...
> Obviously you can't have two different versions of the same package
> with the same name in the same python installation (how do you choose
> which one you mean with import numpy.)
> I think there were problems with the path so when a new numpy is
> installed in 2.5/Extras/lib/site-packages it is actually after the
> existing one on the path and doesn't get picked up. Even if it does
> work, the worry is that you're changing a supplied component and Apple
> stuff might depend upon the version supplied (or other software people
> distribute to use the 'system' python might expect it to be there).
This is not entirely accurate on OS X 10.5. If you install anything
using the system python, it is put in
/Library/Python/2.5/site-packages. Apple's system-supplied packages
are kept in /System/Library/Frameworks/Python.framework/... and, as
you note, the site-packages directory in
/System/Library/Frameworks/Python.framework does come first on the
sys.path. In this way, it is very difficult to override the
Apple-provided packages in a way that breaks system tools that depend
on them. HOWEVER, if you install your packages using setuptools
(including an updated numpy), setuptools will place them first on the
sys.path at import (Apple's tools intentionally restrict their
sys.path to the System/Library/Frameworks/Python.framework
site-packages for this reason). So, if you use setuptools to install
numpy, matplotlib, even Twisted (as of version 8, it is
easy_install-able), etc., you can continue to use the system python
without fear of messing up apple's system tools and without having to
install a separate python instance in /Library/Frameworks.
Apple did a pretty good job on this one for Leopard. As others have
noted, sticking with this system python gains you dtrace support, and
continued improvements from Apple (many apple tools now use python
> I think theres much less chance of problems using the system python
> for system things and leaving it well alone - and installing the
> python.org for everyday use. The only problem with this is that the
> system python works with dtrace while the normal one doesn't...
>> I guess I always feel a sense of uncertainty with having two separate
>> Python installations as to which actually gets used in any particular
>> situation. I appreciate that for experts who use Python daily, this
>> isn't an issue, but for someone like myself who may have gaps of
>> several months between projects that use Python, this is a real issue
>> as I forget those kinds of subtleties.
> Numpy-discussion mailing list
More information about the Numpy-discussion