How should multiple (related) projects be arranged (structured) and configured so that they can share code, have a related package structure and enable proper unittesting, and ensuring no namespace collisions

[bruno at modulix]

ToddLMorgan at gmail.com wrote:
> Summary:
(snip)
> 
> I'm working on a few projects concurrently so I have tried to
> arranged my projects like this:
> 
> COMMON
> src
>         a.b.c.common
> test
> 	a.b.c.common
> 
> APP1
> src
>          a.b.c.app1
> test
>          a.b.c.app1
> 
> APP2
> src
>          a.b.c.app2
> test
>          a.b.c.app2
> 
> 
> But it has not worked due to import/from issues. It appears that using
> a common base package hierarchy (as is standard practice in the java
> world) caused issues. Ie not able to use "a.b.c" as the base
> package for all my projects, in order to avoid namespace collisions.

What you need to understand here is that Python's packages/modules
system is directly tied to the filesystem. A package is a directory with
a __init__.py file and possibly modules and sub-packages in it, and the
package name is the directory name (plus parents packages for
sub-packages). You *cannot* add arbitrary prefix like 'a.b.c' to the
package name.

Regarding import problems, I suggest that you re-read:
http://www.python.org/doc/2.4.2/tut/node8.html#SECTION008400000000000000000
with particular attention to 6.4.2.

Note that you can dynamically modify sys.path - this may solve some
problems with imports !-)

Hoping some guru will be more helpfull...
-- 
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb at xiludom.gro'.split('@')])"