[Distutils] People want CPAN :-)

[David Cournapeau]

Ian Bicking wrote:
> I don't think changing distutils to improve error output would be hard
> at all.  It looks like there's a line in distutils.core that catches
> these exceptions (and doesn't look like it actually catches all
> exceptions?), and that can just be fixed.

I agree this is one of the thing which can be improved without
unintended consequences.

>
> Another topic that has come up: I do agree subclassing makes it really
> hard to have multiple lines of development (specifically something
> like Setuptools or Distribute, along with ad hoc development in
> setup.py files).  But I think that can be resolved.  Perhaps, for
> instance, Distribute can have implementations of commands like build,
> that can easily be customized or extended without subclassing (e.g.,
> by pre-build or post-build functions).

In numpy's case, we subclass the Distribution class mainly to add new
data which are shared within commands (for example, to build pure C
libraries made available to 3rd parties, or to keep track of the scons
scripts).

I have myself tried the pre/post hooks for commands (for
numpy.distutils), but I did not go very far: the problem was almost
always linked to commands which need to share knowledge from each other.
OTOH, I tried this when I started pocking into numpy.distutils 2 years
ago, maybe I could go further today.

Some things are fixable in distutils: for example, to build things, you
should be able to get rid of the imperative operations, and have instead
of registry of extension -> action (ala scons/waf). This would make
adding new tools (cython, assembly, etc...) easier, as you would add
tools through a registry instead of overriding build_ext as currently
done by e.g. numpy.distutils or cython.distutils. Doing so while keeping
backward compatibility would be hard, though.

>   I'd really be shocked if a
> rewrite of distutils was necessary, or even necessary to simplify
> things.

That's the opposite of my own experience. I think I have given several
reasonable examples of shortcomings of distutils: I would be glad to
hear that each of them has a simple solution which is
backward-compatible in distutils.

But another way to look at it is to ask: What is there in distutils that
you would consider important to keep ? It is important that people who
maintain packages do not have to rewrite their setup to a new
hypothetical system: asking thousand of developers to rewrite their
setup would be insane. But this can be done without being tied to
distutils API.

David