konrad.hinsen at laposte.net
konrad.hinsen at laposte.net
Sat Feb 5 02:09:41 CST 2005
On 04.02.2005, at 23:53, Chris Barker wrote:
>> With only C code and no external dependencies, there is rarely ever a
>> problem, and that's why Numeric is a low-risk package.
> Except that it's setup.py has been broken for the last few releases.
> That's been a problem for a number of users.
> By the way, here OS-X is much better than other systems, it comes with
> lapack built in! (Veclib)
I didn't know it has lapack, I thought it was only BLAS!
> Actually, I disagree. Apple's Python is a better choice (you can't run
> Aqua applications from a fink python, at least I don't think so), but
> we do need to do more to provide easy to install packages for it.
> (there are a lot)
I don't care for Aqua as much as I care for all those nice Python
packages I use every day. With Apple's Python, it's command line
installation (which I don't mind, but many of my users do), or
PackageManager for a select few packages. And I can't my own without
proving my own Web server as well, so package contribution is
> Here Fink drives me crazy. It's a system-within-a-system. I want
I certainly agree on that. I curse Fink about once a week. But in the
absence of an alternative, Fink is better than no Fink.
> on my Mac to fit in well with my Mac. If there was a fink-like system
> (I haven't yet tried darwinports or Gentoo) that didn't duplicate
> Apples supplied stuff with incompatible versions (Python, X11), I'd be
> much happier.
Agreed. But there isn't.
>> The net result is that I still don't have SciPy on my Mac
> Me neither, though I don't think it's SciPy's fault. The core problem
> is that
Attributing fault makes little sense in the OpenSource world.
> there aren't all that many people using OS-X developing Python
> packages, and Apple has, of course, made OS-X just different enough
> from other unices to require some work (or take the easy way and use
> fink, but then it
Not really, you can do command-line installation ("python setup.py...")
just like on any other Unix, usually without any modification. The
problem is that Mac users expect installers.
It should be possible to extend distutils for making Mac installers
just like it can make RPMs and Windows installers. I suppose nobody
looked into this because the Apple Python community is divided into
those who come from the Unix world and go for Fink, and those who come
from pre-10 MacOS and go for MacPython plus PackageManager.
> What's the distinction? Again, Apple doesn't provide f77. That's been
> a stopper for me.
I guess Apple's point of view is that you should buy a compiler. But
they could easily add g77 to their developer CD, so there is indeed
> This is a key issue with all open-source projects (at least ones that
> aren't funder). We all do the easiest thing to get the functionality
> we need. If we combined all our duplicate efforts, we'd be in great
> shape, but an any given moment, I mostly need to get my job done, not
> make a better SciPy, or whatever.
Right. But I still wonder why non-scientific projects (e.g. Python
itself, or Linux) don't suffer so much from this problem. The larger
potential developer base is probably just one part of the answer.
BTW, there is a scientific study of the Python development process that
most Pythoneers are probably not aware of but which I think is quite
interesting: "A Methodological Framework for Socio-Cognitive Analyses
of Collaborative Design of Open Source Software" by W. Sack, F.
Détienne, J-M. Burkhardt, F. Barcellini, N. Ducheneaut, and D.
Mahendran. Easy to find via Google.
More information about the Numpy-discussion