Opened 8 years ago

Closed 8 years ago

#14815 closed (duplicate)

app "labels" are ambiguous and cause bugs in

Reported by: Paul Winkler Owned by: nobody
Component: Core (Other) Version: 1.2
Severity: Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


In several places in django/db/models/, 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 commands ambiguous at best.

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

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

If I do sqlall admin, it prints only the SQL for

This is broken in several obvious ways:

  • The app chosen is inconsistent between the two commands
  • It is impossible for me to tell test to test only django.contrib.admin
  • It is impossible for me to tell 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

Change History (2)

comment:1 Changed 8 years ago by Łukasz Rekucki

See a related ticket #3591 and this branch: (it doesn't solve exactly this problem, but makes a step forward a reasonable solution). Backwards compatibility is the main problem here.

comment:2 Changed 8 years ago by Gabriel Hurley

Resolution: duplicate
Status: newclosed

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

Note: See TracTickets for help on using tickets.
Back to Top