[Distutils] People want CPAN :-)
david at ar.media.kyoto-u.ac.jp
Wed Nov 11 10:46:55 CET 2009
Tarek Ziadé wrote:
> On Wed, Nov 11, 2009 at 7:05 AM, David Cournapeau
> <david at ar.media.kyoto-u.ac.jp> wrote:
>> Exactly. The fact that we in numpy consider distutils backward
>> compatibility not worth the cost, even though we are most likely the
>> most tied up with distutils, is quite telling about the state of affairs
> That doesn't prove Distutils can't evolve.
No, but that's not the point I was trying to make: I meant that we
consider the distutils API not to be a significant asset, and would be
happy to throw away all numpy.distutils for a significantly better
system. We now have two build systems in numpy (one based on scons): I
think it takes me 5 to 10 times more effort on average to add a feature
to the distutils-based compared to the scons system. There are some
features I can not implement because I have not find a solution to it in
distutils. There are arbitrary limitations like the inability to call
commands directly from setup.py, retrieve global informations from
setup.py, classes which behave differently on different platforms.
Example: how to retrieve the install prefix in setup.py. You need a good
understanding of distutils to understand why it is so complicated, and
the example shows almost everything that's wrong in distutils design.
Many expectations are undocumented, like what method/class can be called
where and when. All this implicit behavior is part of the API, and
that's not documented anywhere that I know of.
Also, what happened in python 2.6.3/2.6.4 w.r.t. distribute has happened
quite often for numpy.distutils, and I consider it inherent to distutils
way of working.
> If the Numpy projects made some refactoring/improvement, why the
> project didn't try to push
> it back in Distutils itself ?
They are not improvements or refactoring for most part. They are things
quite specific to our needs: fortran support, support for our internal
code generator, swig, f2py, etc... A few things could be useful to
distutils, like manifest support for mingw for 2.6 and later, as well as
basic autoconf-like tests (checking for functions, type, type size,
etc...). We would be happy to contribute patches to Distribute if this
is considered useful.
More information about the Distutils-SIG