Folks: I just added this note to the bug tracker, but I'm not sure if anyone who has the ability to commit fixes to setuptools is reading all updates to all tickets on that tracker, so I wanted to draw attention to it here: http://bugs.python.org/setuptools/issue20 # package required at build time seems to be not fully present at install time? """ Okay Brian Warner and I just tracked this issue down a bit, since it is blocking the release of the next version of the Tahoe Least-Authority Filesystem. It turns out that when setuptools builds Twisted from source in a "setuptools sandbox", that this causes the import of a few things including "twisted" and "twisted._version". These get added to sys.modules, and then this side-effect on sys.modules is not undone after Twisted has been built and installed, so in a sense changes to sys.modules can "leak" out of the sandbox. Nevow's build process then tries to import twisted.components, which was not imported by Twisted's build process, so it isn't already in sys.modules, but also cannot be imported from the newly installed Twisted, because "twisted" is already in sys.modules (with a directory location of ".", which refers to a temporary directory when it was being built which has since been deleted). This is why Nevow cannot be installed in the same setuptools process as Twisted was. A good way to improve this would be to make the setuptools sandbox "tighter" -- make it so that the act of building and installing one distribution doesn't have side-effects on the sys.modules which effect the attempt to later build another distribution. A good way to do this is to use a subprocess. If you don't want the code that you are about to execute to have side-effects on your Python state, then execute that code in a subprocess. Another way to fix this would be to figure out which names had been added to sys.modules during the "build in a sandbox" and clean them out afterward. """