Sotto-applicazioni Django e struttura del modulo

Question

Sto sviluppando un'applicazione Django, che è un sistema di grandi dimensioni che richiede più sotto-applicazioni per mantenere le cose in ordine. Pertanto, ho una directory di livello superiore che è un'app Django (in quanto ha un file vuoto models.py) e più sottodirectory, che sono anche applicazioni in sé stesse.

Il motivo per cui ho implementato la mia applicazione in questo modo è perché le sotto-applicazioni sono separate, ma non verrebbero mai utilizzate da sole, al di fuori dell'applicazione madre. Pertanto non ha senso distribuirli separatamente.

Quando si installa la mia domanda, il file delle impostazioni deve includere qualcosa di simile:

INSTALLED_APPS = (
    ... 
    'myapp', 
    'myapp.subapp1', 
    'myapp.subapp2', 
    ... 
) 

... che è ovviamente non ottimale. Questo ha anche il risultato un po 'sgradevole di richiedere che tutte le sotto-applicazioni siano indicate con il loro nome "interno" (ad esempio subapp1, subapp2 ecc.). Ad esempio, se voglio ripristinare le tabelle del database per subapp1, devo digitare:

python manage.py reset subapp1 

Questo è fastidioso, soprattutto perché ho un sub-app chiamato core - che rischia di conflitto con il nome di un'altra applicazione quando la mia applicazione è installata nel progetto di un utente.

Sto facendo questo in modo completamente errato, o è lì per forzare queste app "interne" a cui fare riferimento con il loro nome completo?

Answer 1

Lo stai facendo nel modo giusto, dal momento che lo stesso Django lo fa in questo modo. L'app di amministrazione, ad esempio, è registrata in INSTALLED_APPS come django.contrib.admin, ma per ripristinarla è necessario utilizzare manage.py reset admin, e infatti, manage.py reset django.contrib.adminnon funziona.

Potrebbe essere considerato come un bug in Django ...

Tuttavia, non dovrebbe essere interessato da conflitti tra i nomi, perché si dovrebbe sempre eseguire Django all'interno di un ambiente virtualenv, isolata dal resto del installazione python. Questa è una soluzione immensamente più potente e flessibile di eseguire django su una normale installazione python. Ulteriori informazioni, ad esempio, qui: http://mathematism.com/2009/jul/30/presentation-pip-and-virtualenv/