Opened 13 years ago
Closed 11 years ago
#16883 closed Bug (fixed)
Importing models.py from not-installed app prevents any other app with that label from loading
Reported by: | Carl Meyer | Owned by: | nott |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | dev |
Severity: | Normal | Keywords: | app-loading |
Cc: | Triage Stage: | Accepted | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
If a models.py from an app that is not listed in INSTALLED_APPS happens to be imported for whatever reason, that (not-installed) app takes over the app-label in the app cache, making it impossible for any app actually in INSTALLED_APPS to use that app-label. This is wrong - an import should not have such a side effect. INSTALLED_APPS should be the arbiter of what apps are actually found in the app cache.
The fix for #16283 worked around this problem and removed the immediate symptom, but didn't address the underlying issue.
The fix for #15866 addressed a similar issue, but didn't fix this.
This may be fixed in the app-loading branch, and in any case is closely-related to the changes there.
Attached tarball is a simplest-case settings.py and app demonstrating the issue; run "manage.py validate" to see the problem. The models from contrib.auth are being validated even though that app is not installed, simply because its models.py has been imported. The presence of another INSTALLED_APP with the "auth" app-label causes the app cache to be confused into thinking that contrib.auth is actually installed, when it is not.
Attachments (1)
Change History (4)
by , 13 years ago
Attachment: | uninstalled-models.tgz added |
---|
comment:1 by , 13 years ago
Triage Stage: | Unreviewed → Accepted |
---|
Downloaded the demo and validated the problem
comment:2 by , 11 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:3 by , 11 years ago
Keywords: | app-loading added |
---|---|
Resolution: | → fixed |
Status: | assigned → closed |
I believe this is solved by the app loading refactor in 1.7, or will be in 1.9. Such invalid combinations will raise an exception, possibly after a deprecation path.
project demonstrating the problem