Sous-applications et structure de module Django

Question

Je développe une application Django, un grand système qui nécessite plusieurs sous-applications pour garder les choses propres. Par conséquent, j'ai un répertoire de niveau supérieur qui est une application Django (car il a un fichier models.py vide), et plusieurs sous-répertoires, qui sont aussi des applications en eux-mêmes.

La raison pour laquelle j'ai déposé ma demande de cette manière est que les sous-applications sont séparées, mais qu'elles ne seront jamais utilisées seules, en dehors de l'application parente. Il est donc absurde de les distribuer séparément.

Lors de l'installation de mon application, le fichier de paramètres doit inclure quelque chose comme ceci:

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

... qui est évidemment suboptimale. Cela a également le résultat légèrement désagréable d'exiger que toutes les sous-applications soient désignées par leur nom "interne" (c'est-à-dire subapp1, subapp2 etc.). Par exemple, si je veux réinitialiser les tables de base de données pour subapp1, je dois taper:

python manage.py reset subapp1 

Ceci est gênant, surtout parce que j'ai une sous-application appelée core - qui risque de conflit avec le nom d'une autre application lorsque mon application est installée dans le projet d'un utilisateur. Est-ce que je fais cela complètement à tort, ou est-ce qu'il y a loin de forcer ces applications "internes" à être désignées par leur nom complet?

Answer 1

Vous le faites de la bonne façon, puisque django le fait de cette façon. L'application d'administration par exemple est enregistrée dans INSTALLED_APPS comme django.contrib.admin, mais pour le réinitialiser, vous devez utiliser manage.py reset admin, et en effet, manage.py reset django.contrib.adminne fonctionne pas.

Il pourrait être considéré comme un bogue dans django ...

Cependant, vous ne devriez pas être concerné par les conflits de noms, parce que vous devez toujours exécuter django dans un environnement virtualenv, isolé du reste du installation de python. C'est une solution immensément plus puissante et flexible que l'exécution de django sur une installation python ordinaire. Plus d'infos, par exemple, ici: http://mathematism.com/2009/jul/30/presentation-pip-and-virtualenv/