How to manage several python subprojects with setuptools?

Question

I'm wondering about the correct/easiest/most pythonic way of dealing with subprojects that you want have using the same base package. We currently have a file structure like this:

trunk\
    proj1\setup.py
          company_name\__init__.py + proj1's code
    proj2\setup.py
          company_name\__init__.py + proj2's code

We want to keep the namespace company_name common to all our projects (maybe this itself is unpythonic?) but when proj1 and proj2 are installed in develop mode, the first one installed gets broken. It looks like import company_name... gets confused on which company_name package to look in and it grabs the first/last/random one.

How would this normally be handled in a larger python project? Is it possible to resolve this with a setup.py in the trunk that builds some sort of mega-egg? I haven't found any relevant info on google or stack, so any information even just links are greatly appreciated!

---

edit: I just tried adding a setup.py in the root folder with

...    
namespace_packages = ['company_name'],
package_dir = {'company_name' : ['proj1/company_name', 'proj2/company_name']}
...

with appropriate pkg_resources.declare_namespace(__name__) in the __init_.py files, but ./setup.py bdist_egg just gives:

error in company_name setup command: Distribution contains no modules or packages for namespace package 'company_name'

Answer 1

While I can't vouch for the pythonity of my solution, I did finally get the different applications running together alright. I was on the right track with the namespace packages, but instead of trying to have one super-project in the trunk, I added the namespace_packages line in the setup.py of each individual project. This led to the behaving properly when installed together, sharing the company_name namespace as intended.

Anyone who wants to chime in on wether this is a reasonable python solution, I'm still interested to hear if this is "the way it's done". It feels right, but that could be because it mimics the java style I'm more used to.