[Numpy-discussion] Problem with numpy on Leopard

[Ned Deily]

In article <472A5D42.5070500 at noaa.gov>,
 Christopher Barker <Chris.Barker at noaa.gov> 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,
 nad at acm.org