Stefan Seefeld wrote:
- 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 ?
The 'setup.py' [or whatever you want to call it] script. Reduce the amount of code the module developer needs to write. For simple modules and packages, this could (and should) be zero.
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.
Of course. My point is that some of this data shouldn't be in the setup scripts, and at least some of the rest should be automatically determined by the system rather than specified by the user (unless they need to override the automatics): - Put metadata (by which I mean information describing the module/package itself; its name, version, author, dependencies, etc) into a standard metadata file, e.g. meta.txt, within the package. - Put data/code used to build the distro into a build.py script. Put data/code used to install the distro into a install.py script. i.e. There should be a clear distinction made between information describing the module and information used merely in building/installing it (custom paths, framework bindings, etc). These are two very different things and should be handled accordingly. [Note: any time I say 'metadata' I'm referring to the former, not the latter.] With DU1, all this data is squidged into setup.py. This is suboptimal: it's not very convenient to read/edit, and there's some unnecessary duplication of metadata occurring over the build/install process as some of this data gets duplicated into PKG-INFO (which'd be unnecessary if it was put into a meta.txt file in the first place). Often the only unique information stored in setup.py is said 'metadata', which is really a suboptimal arrangement. (Plus stuff like sub-package names, which can and should be gotten rid of in most, if not all, cases.) Maybe a practical example'd help: Current: from distutils.core import setup setup(name = 'HTMLTemplate', version = '0.4.3', description = 'HTML templating engine.', author = 'HAS', author_email = '', # see Manual.txt url='http://freespace.virgin.net/hamish.sanderson/htmltemplate.html', license = 'LGPL', platforms = ['any'], long_description = 'HTMLTemplate converts XML/HTML/XHTML templates ...', py_modules = ['HTMLTemplate'], ) Suggested: - meta.txt version 0.4.3 description HTML templating engine author HAS author email see Manual.txt url http://freespace.virgin.net/hamish.sanderson/htmltemplate.html license LGPL platforms any long description HTMLTemplate converts XML/HTML/XHTML templates ... - install.py #!/usr/bin/env python from DU2 import install install() - build.py #!/usr/bin/env python from sys import argv from DU2 import build build(argv[1], omit='\.pyc$') Eliminating unnecessary duplication means the name shouldn't need to be declared more than once (i.e. the package folder name). The py_modules value is, by default, unnecessary. PKG-INFO is obsolete. README can be auto-generated (though I kinda wonder just how useful this really is and if it could be eliminated altogether). Both install.py and build.py are generic scripts: the former can be automatically inserted into the distro, the latter run from the shell as a standard build script. It'll still scale up just as well as DU1, so that's not a concern. The aim here is to handle the simplest and [presumably] most common cases more cleanly. HTH has -- http://freespace.virgin.net/hamish.sanderson/