Survey of complex usage of distutils.

[Graham Fawcett]

Fernando Perez <fperez528 at yahoo.com> wrote in message news:<ba0ke0$cao$2 at peabody.colorado.edu>...

> Pyrex also seems to have extended distutils a bit, although not as radically as
> scipy.

I wrote the original Pyrex distutils code... it's not very
complicated, just subclassed distutils.command.build_ext.build_ext to
allow for .pyx->.c generation before calling the compiler.

Py2exe comes to mind as a tool that extended Distutils in a similar
fashion, by providing a custom py2exe command.

On a slightly offtopic aside, I'd love to see a rework of distutils
that better separated the various concerns that it addresses: notably,
separating metadata from packaging from installation. A single setup()
call that globs all this together has led to some interesting
acrobatics in the past, and will sadly lead to more (esp. as
technologies like the Python package index become more robust). My two
cents would be to place package metadata in its own file
('__about__.py' perhaps), dependency data in another, and place
install-target hints in a third file, with toolchain support to
facilitate local customization and the final install. Distutils is
remarkable, and of course it's ubiquitous, but IMHO it's a bit on the
baroque side.

-- G