Quoth Andrew Dalke, on 06 March 1999:
My current task here at Bioreason is to set up a build/distrib system for our projects. We're developing pure Python modules, Python extensions in C/C++, and stand-alone C++ executables. I'm trying to get a basic system that lets use work with these in a standard framework and supports automatic regression tests with the results emailed or sent to a status web page.
Hmmm, from the first paragraph, it sounds like there's the potential for a lot of overlap with Distutils -- or, to look at it more positively, a lot of potential for you to use Distutils!
The rest of your post diverges a bit from this; certainly, stock, out-of-the-box Distutils won't be able to handle all the neat stuff you want to do. However, the architecture is quite flexible: module developers will easily be able to add new commands to the system just by defining a "command class" that follows a few easy rules.
I posted a design proposal to this list back in January; you might want to give that a look. I finally got around to HTMLizing it and putting it on the Distutils web page a week or so ago, but hadn't announced it yet because I wanted to tweak it a bit more. So much for that -- consider this the announcement. You'll find the design proposal at
By no means is it a comprehensive design; since I've finally started implementing the Distutils (shh! it's still a secret!), I've found all sorts of holes. However, it gives a good idea of the level of flexibility I'm aiming for.
Note that one big difference between your idea and Distutils is that we're avoiding dependence on Makefiles: for the most part, they're not needed, and they're unportable as hell (as you're finding out). Make should be used to carry out timestamp-based file dependency analysis, which means it's just great for building C programs. When you use it mainly to bundle up little sequences of shell commands, you're misusing it. (For the ultimate example of Makefile abuse, see any Makefile created by Perl's MakeMaker module. The most astonishing thing is that it all *works*...)
Let me explain that last one some more. It seems that Perl's "pod" format is the easiest to learn and use.
Yes. XML is waaay cool, but pulls in a hell of a lot of baggage. Until that baggage is standard everywhere (hello, Python 1.6 and Perl 5.006! ;-), low-overhead light-weight solutions like pod are probably preferable. Heck, even when all the world is Unicode and XML for everything, low-overhead and light-weight will still be nice (if only to remember how things were, back in the good ol' days).
Is there a Python way to read/parse pod files? If not, using perl for this is fine with us.
As Fred said, it *should* be trivial. It's a bit trickier if you want a really flexible framework for processing pod; see Brad Appleton's Pod::Parser module (available on CPAN) for that. The current generation of pod tools that ship with Perl are getting a bit long-in-the-tooth; they all have their own parsers, and unsurprisingly have diverged somewhat over the years. Hopefully Pod::Parser will start to fix this. My recommendation: spend a few hours learning to use Pod::Parser, and then write your own custom pod tools (yes, in Perl ;-). Slightly less trivial than writing your own custom, limited parser (in either language), or using pod2text, but should be more robust and scalable.
Anyways, with any luck the Distutils CVS archive will be a lot busier within a week or so -- so there might actually be something that you (and everyone else on this SIG!) can muck around with.
Keeping my fingers crossed (except while writing code) --