Thanks for all the prompt helpful responses :- ) I have read and reread section 6.4 -> of the python docs and it doesn't really help me.
Just a couple of clarifications. I am already using a VCS (Version Control System) - subversion actually. When I mentioned a clear separation of production and test code I was more referring to this sort of arrangement: src a.b.c.common a.b.c.common.test which I believe is bad versus the clearer physical separation test a.b.c.commom.test The first option has the testing code within the same folder hierarchy which makes it harder to separate the two physically at "release" time without writing some complicated scripts to selectively exclude items. In the Java world the second option is the standard, and my preference if it's possible. I suspect that some of my import / from problems stem from the fact that I want to use a standard base package for all my projects to avoid namespace issues. ie all my projects use packages of the form a.b.c.projectName where a.b.c is my namespace (dns address actually) a.b.c.common a.b.c.project1 a.b.c.project2 Is this not the way python projects should be packaged? Is there a problem with having a common base package name like this? ie does the first instance of the package a.b.c effectively mask out the others so that if a.b.c.common occurs first in the PYTHONPATH then a.b.c.project1 will never be found as the "a.b.c" package is only loaded from the a.b.c.common folder? Does anyone else have any issues with running a master test suite and indvidual tests. It seems that if I set up the imports/froms for the master testsuite then I can't run the tests individuallly and vice versa ... unless I remove all packages and have a single flat directory. There has got to be big projects written in python that need to separate out their testing code according to some logical grouping. thanks Todd -- http://mail.python.org/mailman/listinfo/python-list