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.
As others already pointed out, what you suggest doesn't really change anything: 'setup.py' is just a facade to access distutils' functionality. building and installing *is* already controlled by two distinct objects ('commands').
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.
what do you want to reuse that you can't right now ? As we all agree the 'build' class should be more polymorphic, i.e. it should be able to wrap your own build system for a component of the package (and that's one thing where DU1 lacks most IMO). However, in order for 'build' and 'install' to work smoothly together, they both have to respect some conventions, for example use some common metadata format to share information about the things to be installed.