views:

214

answers:

1

I am developing a Django application, which is a large system that requires multiple sub-applications to keep things neat. Therefore, I have a top level directory that is a Django app (as it has an empty models.py file), and multiple subdirectories, which are also applications in themselves.

The reason I have laid my application out in this way is because the sub-applications are separated, but they would never be used on their own, outside the parent application. It therefore makes no sense to distribute them separately.

When installing my application, the settings file has to include something like this:

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

...which is obviously suboptimal. This also has the slightly nasty result of requiring that all the sub-applications are referred to by their "inner" name (i.e. subapp1, subapp2 etc.). For example, if I want to reset the database tables for subapp1, I have to type:

python manage.py reset subapp1

This is annoying, especially because I have a sub-app called core - which is likely to conflict with another application's name when my application is installed in a user's project.

Am I doing this completely wrongly, or is there away to force these "inner" apps to be referred to by their full name?

+2  A: 

You are doing it the right way, since django itself does it that way. The admin app for instance is registered in INSTALLED_APPS as django.contrib.admin, but to reset it you have to use manage.py reset admin, and indeed, manage.py reset django.contrib.admin does not work.

It could be considered as a bug in django...

However, you should not be concerned by name conflicts, because you should always run django inside a virtualenv environment, isolated from the rest of the python installation. This is an immensely more powerful and flexible solution than running django on an ordinary python installation. More info, for instance, here: http://mathematism.com/2009/jul/30/presentation-pip-and-virtualenv/

Olivier
I'm already using virtualenv, but this doesn't solve the problem - as a user is actually quite likely to make an app called `core` within their project, which would then conflict with my `core` app.
Rob Golding
Sure, this is a limitation. I submitted a patch: http://code.djangoproject.com/attachment/ticket/13323/applabel.diffSee also the corresponding ticket. I'm not sure the problem is completely solved, though.
Olivier
I had no idea this was being discussed, thanks. Ticket #3591 looks most promising, but it's not on the list for 1.2 so I guess I'll just have to work round the issue until something happens. I don't fancy running a custom installation of Django for this project :).
Rob Golding