app "labels" are ambiguous and cause bugs in manage.py

[Paul Winkler]

In several places in django/db/models/loading.py, apps are looked up
via a non-namespaced name: that is, if your settings.INSTALLED_APPS
contains 'django.contrib.admin', the string 'admin' is used to look up
apps. This is done eg. in get_app().*

This is bad because it requires the last part of the dotted name - the
"app label" - to be unique across all installed apps, which I think is
an undocumented assumption. If there are duplicates, it makes the
behavior of manage.py commands ambiguous at best.

Here's one bug: my settings.INSTALLED_APPS contains among other things ('obadmin.admin', ... , 'django.contrib.admin', ...)

If I do manage.py test admin, it runs only the tests from obadmin.admin.

If I do manage.py sqlall admin, it prints only the SQL for
django.contrib.admin.

This is broken in several obvious ways:

• The app chosen is inconsistent between the two commands
• It is impossible for me to tell manage.py test to test only django.contrib.admin
• It is impossible for me to tell manage.py sqall to give me only the sql for obadmin.admin

"Namespaces are one honking great idea. Let's do more of those."

I don't know how hard it would be to solve this while preserving
backward compatibility. Would it be possible to allow specifying the
full dotted name of the app, and fall back to the current behavior if
the name doesn't contain dots? Maybe the various dicts on AppCache
could have both labels and dotted names as keys?

• Resolving the label to a module is also done in get_models(app_mod),

via the cache, even though the app_mod argument is already a
module. This might actually qualify as a separate bug: get_models
should always return models belonging to the app_mod passed in; it
should never use the name of that module to find models in a different
module.

[Łukasz Rekucki]

See a related ticket #3591 and this branch: ​http://code.djangoproject.com/browser/django/branches/soc2010/app-loading (it doesn't solve exactly this problem, but makes a step forward a reasonable solution). Backwards compatibility is the main problem here.

[Gabriel Hurley]

As lrekucki already pointed out, this is a duplicate of #3591.