[Numpy-discussion] Problem with numpy on Leopard
Thu Nov 1 18:46:01 CDT 2007
In article <472A5D42.firstname.lastname@example.org>,
Christopher Barker <Chris.Barker@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.
More information about the Numpy-discussion