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