Come gestire diversi sottoprogetti Python con setuptools?

Question

Mi chiedo quale sia il modo corretto/più semplice/più sdolcinato di gestire i sottoprogetti che si desidera utilizzare con lo stesso pacchetto di base. Al momento abbiamo una struttura di file come questo:

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

vogliamo mantenere la company_name namespace comune a tutti i nostri progetti (? Forse questo è di per sé unpythonic), ma quando proj1 e proj2 sono installati in modalità sviluppo, il primo installato viene rotto. Sembra che import company_name... si confonda sul pacchetto company_name in cui cercare e afferra il primo/ultimo/random.

Come si gestirà normalmente questo in un progetto Python più grande? È possibile risolvere questo problema con un setup.py nel bagagliaio che costruisce una sorta di mega-uovo? Non ho trovato nessuna informazione pertinente su google o stack, quindi qualsiasi informazione, anche solo i collegamenti, è molto apprezzata!

---

edit: ho appena provato ad aggiungere un setup.py nella cartella principale con

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

con adeguate pkg_resources.declare_namespace(__name__) nei file __init_.py, ma ./setup.py bdist_egg dà solo:

errore comando setup nome_azienda: la distribuzione non contiene moduli o pacchetti per il pacchetto namespace 'company_name'

Answer 1

Mentre non riesco a garantire per la pitonimità della mia soluzione, finalmente ho fatto in modo che le diverse applicazioni funzionassero insieme. Ero sulla strada giusta con i pacchetti namespace, ma invece di provare ad avere un super progetto nel bagagliaio, ho aggiunto la riga namespace_packages nel setup.py di ogni singolo progetto. Ciò ha comportato il comportamento corretto quando installati insieme, condividendo lo spazio dei nomi company_name come previsto.

Chiunque voglia intervistare se questa è una soluzione python ragionevole, sono ancora interessato a sapere se questo è "il modo in cui è fatto". Sembra giusto, ma potrebbe essere perché imita lo stile java a cui sono più abituato.