Hey, Couple more thoughts to add to yesterday's: - Decoupling DU build procedures from DU installation procedures also implies delegating control of building and installing to separate scripts (e.g. 'build.py', 'install.py'), rather than having a single 'setup.py' script doing double duty. Superficially this may sound like it's creating more(!) work for module developers, but bear in mind my goal of making these scripts more generic so that in most cases the module developer can simply [re]use existing ones rather than have to code new versions each time. - Regarding the "human-readable flag" aspect of setup.py, as this does cause some concern... In an _ideal_ world, the absence of a setup.py script would simply indicate that a module could be installed via a generic installation process. This _not_ being an ideal world, however (i.e. non-DU-compatible modules also lack a setup.py script, making it hard to tell the two forms apart), there's no reason a standard 'install.py' script couldn't always be included. Also, removing metadata from setup scripts means that most of the time 'install.py' will be a completely generic script that can be automatically added to the .zip at build-time; one less thing for the module developer to have to do themselves. Cheers, has -- http://freespace.virgin.net/hamish.sanderson/