[SciPy-dev] scipy_distutils/*_info.py files

eric eric at scipy.org
Tue Feb 19 21:44:20 CST 2002

Hey Fernando,

> > Agreed.  As long as we don't get in the business of trying to write
autoconf. :-)
> Have you ever looked at scons (http://www.scons.org)? I know it looks like
> more of a make than autoconf replacement, but it might be worth a look. It
> would be great if here we could concentrate on the Sci part of SciPy and
> leverage other's work for the 'software engineering' part. I realize you
> guys have already been forced to do a ton of work around distutils
> limitations (frankly it's a pretty primitive system, and I'd argue one of
> Python's Achilles' heels).

Currently, scons is general purpose like make.  It doesn't serve the same
as distutils -- i.e. building Python extensions as automatically as possible.
is a lot of overlap though, and SCons would make a much more powerful
for the second generation of distutils.  I'm very hopeful this will happen.  For
now I think distutils is the best option.  It ain't always pretty, but you can
usually get the job done.

> I recently also saw QMTest for testing at
> http://www.codesourcery.com/qm/qmtest, also Python-based.

qmtest is general purpose also.  It uses web based entry and reporting for all
of its test currently.  The only other option for creating tests is to write
them in XML.  I think this will eventually change.  For now, unittest.py plus
maybe 500 or 1000 other lines of code provide a reasonable test framework that
can be defined in Python and executed from the Python interpreter.

> I may be completely off-mark here, I'm just thinking of how we can best use
> other's work for some areas. The task ahead for scipy is big enough as it is.
> But you guys may have already gone over this, so feel free to shoot me down
> if I'm just blabbering nonsense.

All suggestions welcome!  We've looked at quite a few options, but not all of
them by any stretch of the imagination.


More information about the Scipy-dev mailing list