I'm a distutils newbie so I'm just trying to find my way around. I notice that even though (e.g.) numpy is built using distutils, the windows binary zipfile does not come with a setup.py for installation. The setup is pretty brain-dead (just unzip to a particular location) but I'm thinking of a future where Python binaries on a particular platform have a known structure so that they can be installed in a generic way. In other words, I'd like it to be more brain-dead: more like an RPM or MSI where the internal binary distribution structure is well-known. I tried to implement this for a few packages as an experiment (first not using distutils, and then using distutils). I decided that all of the packages would have a top-level "install.py". I was writing small tools to find the Python lib directory, copy the files and so forth but then I realized that I was duplicating some of the work of distutils (which does have an install option, after all). So then I started to use distutils and the "setup.py" convention. The structure of my modules is /foo/__init__.py /foo/bar/__init__.py /foo/bar/something.pyd Installing the ".py"s is easy because of "packages=". But distutils misses the .pyd. Is it doing the right thing? Or should it blindly copy .pyd's as part of a package. Also, is distutil install supposed to do anything with documentation? It would be nice if there were a standard place for Python module documentation. Paul