Re: [Numpy-discussion] Problem with numpy on Leopard
Hi, The problem will arise for every package, not only numpy, so Apple fixing this is the best solution IMHO. Matthieu 2007/11/1, Brian Granger [EMAIL PROTECTED]: Hi, It turns out that Leopard includes numpy. But it is an older version that won't detect the version string of gfortran correctly (thus preventing scipy from being installed). But, when I downloaded the numpy svn and did python setup.py python was still finding the older version of numpy. The problem is a trivial but unfortunate ordering of things in the default sys.path. Here is the message that I sent to the pythonmac-sig about this: I have been playing around with python on Leopard today. Overall, I am very pleased, but I just ran into a problem that will affect a large number of users. In Leopard, Apple includes a number of python packages in: ls /System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python CoreGraphicseasy_install.pyc setuptools-0.6c7-py2.5.egg-info OpenSSL fetchmailconf.py site.py PyObjC fetchmailconf.pyc site.pyc PyObjC.pth fetchmailconf.pyo site.pyo PyRSS2Gen-1.0.0-py2.5.egg-info libsvn svn PyRSS2Gen.pymacholib twisted PyRSS2Gen.pyc macholib-1.2.1.dev-py2.5.egg-info wx Twisted-2.4.0-py2.5.egg-infomodulegraph wx-2.8-mac-unicode Twisted_Words-0.4.0-py2.5.egg-info modulegraph-0.7.2.dev-py2.5.egg-infowxPython Twisted_Xish-0.4.0-py2.5.egg-info numpy wxPython_common-2.8.4.0-py2.5.egg-info altgraphnumpy-1.0.1-py2.5.egg-info wxaddons altgraph-0.6.8.dev-py2.5.egg-info pkg_resources.py wxaddons-2.8.4.0-py2.5.egg-info bdist_mpkg pkg_resources.pyc wxversion.py bdist_mpkg-0.4.3.dev-py2.5.egg-info py2app wxversion.pyc bonjour py2app-0.4.1.dev-py2.5.egg-info xattr bonjour_py-0.2-py2.5.egg-info pyOpenSSL-0.6-py2.5.egg-info xattr-0.5-py2.5.egg-info dateutil python_dateutil-1.2-py2.5.egg-info zope easy_install.py setuptools zope.interface-3.3.0-py2.5.egg-info At first I was very excited to see that Apple is including things like setuptools, numpy, twisted.. But then I saw that some of the versions are quite old. Naturally, I grabbed the latest numpy version from svn and did a python setup.py install. Everything built just fine, but when I did an import numpy, I got Apples version: import numpy print numpy.__file__ /System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/numpy/__init__.pyc After looking at sys.path, it became clear what the problem is: Running python setup.py install on Leopard causes packages to be installed in the usual: /Library/Python/2.5/site-packages But, Apple put this directory _after_ /System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python in sys.path. This, even if a user installs a newer version of one of these packages, the builtin python will always use Apple's older version. Obviously, I can set PYTHONPATH to get /Library/Python/2.5/site-packages earlier in the sys.path list, but this is going to bite many people. Is this a bug that I should report to Apple, or is there a better work around? Also, this information needs to be posted somewhere so we don't see this question a billion times on various lists over the lifetime of Leopard. Cheers, Brian ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion -- French PhD student Website : http://miles.developpez.com/ Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Problem with numpy on Leopard
Matthieu Brucher wrote: Hi, The problem will arise for every package, not only numpy, so Apple fixing this is the best solution IMHO. It's unlikely they are going to. If they put that stuff there, it's because they are using it for something, not as an (in)convenience to you. I don't recommend using the Python.framework in /System for anything except for distributing lightweight .apps. In that case, you can control your sys.path very well. For regular work, use the binary from www.python.org. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Problem with numpy on Leopard
It's unlikely they are going to. If they put that stuff there, it's because they are using it for something, not as an (in)convenience to you. I don't recommend using the Python.framework in /System for anything except for distributing lightweight .apps. In that case, you can control your sys.path very well. For regular work, use the binary from www.python.org. I agree that they probably won't fix this, but with Leopard, Apple has gone out of their way to integrate the builtin python with PyObjC, the new scripting bridge and Xcode. The python.org binary doesn't have those things, which could be a real barrier to some people. I am going to file a bug report. Brian -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Problem with numpy on Leopard
More evidence that just using the python.org python binary isn't a universal fix for everyone: From a thread on one of the python-dev lists: Which reminds me -- what version of Python is in Leopard? 2.5.1 + most of the patches that will be in 2.5.2 + some additional patches by Apple. AFAIK the latter are some patches to support their build machinery and patches that add support for DTrace. On 11/1/07, Robert Kern [EMAIL PROTECTED] wrote: Matthieu Brucher wrote: Hi, The problem will arise for every package, not only numpy, so Apple fixing this is the best solution IMHO. It's unlikely they are going to. If they put that stuff there, it's because they are using it for something, not as an (in)convenience to you. I don't recommend using the Python.framework in /System for anything except for distributing lightweight .apps. In that case, you can control your sys.path very well. For regular work, use the binary from www.python.org. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Problem with numpy on Leopard
Robert Kern wrote: The problem will arise for every package, not only numpy, so Apple fixing this is the best solution IMHO. It's unlikely they are going to. If they put that stuff there, it's because they are using it for something, not as an (in)convenience to you. I don't recommend using the Python.framework in /System for anything except for distributing lightweight .apps. AARRGG! This has come up before, when IBM was putting python in systems for some reason. Also, anyone remember RedHat, when upgrading python all their stuff would break. The problem there was that they refused, for some unknown reason, to specify a python version in their #! lines, nor did they specify a path (i.e., they used /usr/bin/env python) -- so you couldn't change the default python without all of RedHat's utilities breaking. The issue here is that if Apple had put site-packages on the path before their Extras dir, then when someone did something like install an upgrade to numpy (what a good idea) there is a chance that some Apple-supplied utility that relies on numpy would break. Hence Roberts solution: treat the Apple Python as a system only tool, only to be added to by Apple themselves. I guess that's OK, but it's really silly that it has to be that way. The solution: support versioning of packages in python! This came up some years ago, when wxPython developed a versioning system -- it would have made much more sense for their to be a standard way to do it, but the core folks on python-dev didn't see the point. oh well. The way I see it, python is a very good, robust, general purpose tool. It's a great thing for OS suppliers to provide python for system and users use -- I'd love to see it treated as other system libraries and utilities are, but to do that, there must be a versioning system for packages -- so Apple can use the version they installed, and a user can install and upgrade along side it, and not break anything. It's analygous to shared libraries -- it's insane to use shared libs without versions - we'd have to statically link everything. Having to install all of Python, and all those packages because you want to upgrade numpy just seems crazy. /rant Sorry about that! -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Problem with numpy on Leopard
In article [EMAIL PROTECTED], Christopher Barker [EMAIL PROTECTED] wrote: [...] AARRGG! [...] Hence Roberts solution: treat the Apple Python as a system only tool, only to be added to by Apple themselves. I guess that's OK, but it's really silly that it has to be that way. The solution: support versioning of packages in python! This came up some years ago, when wxPython developed a versioning system -- it would have made much more sense for their to be a standard way to do it, but the core folks on python-dev didn't see the point. oh well. Ah, but there is a de-facto standard multi-platform Python versioning system out there in ever increasing use: setuptools (a.k.a easy_install). It's just *not* *quite* there yet, as in not yet being in the standard library. Still, it is designed to be easily bootstrapped into vanilla systems, it has the best chance of making it there of anything else out there, and the fact that it is plug-compatible with distutils for most applications is a huge plus. The way I see it, python is a very good, robust, general purpose tool. It's a great thing for OS suppliers to provide python for system and users use -- I'd love to see it treated as other system libraries and utilities are, but to do that, there must be a versioning system for packages -- so Apple can use the version they installed, and a user can install and upgrade along side it, and not break anything. It's analygous to shared libraries -- it's insane to use shared libs without versions - we'd have to statically link everything. Having to install all of Python, and all those packages because you want to upgrade numpy just seems crazy. There's another way to look at the issue in the OSX world, though. Apple strongly encourages the use of application packages and the tools provided for Python on OSX, i.e. py2app, make it easy for developers to provide robust, stand-alone applications without dependencies on shared libraries. Yes, that may lead to some wasted disk space, with multiple copies of otherwise potentially sharable libraries hidden under the covers of the application, but delivering a stand-alone application via a single drag-and-drop disk image rather than with an installer that has to manage library dependencies makes the extra disk space a small price to pay. Or, at least, that's what we're encouraged to believe. I do after seeing problems like the one you're wrestling with now. -- Ned Deily, [EMAIL PROTECTED] ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
