Opened 16 years ago
Closed 12 years ago
#9120 closed New feature (fixed)
Improve error reports for exceptions in models.loading.load_app
Reported by: | Henrik Vendelbo | Owned by: | nobody |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | 1.0 |
Severity: | Normal | Keywords: | ImportError, load_app, Error: |
Cc: | dnordberg@… | Triage Stage: | Design decision needed |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
If you old attributes in your model fields or anything else that will raise an exception when trying to load the application models you may get very little error information. In my case all I got was the following:
$ ./manage.py test
Error: cannot import name settings
The exception message is correct, but it didn't really tell me anything useful. If I tried importing settings in a Python shell it worked fine. And if I tried to run any manage.py command, it would fail with the same error message. What was worse, was that I didn't know where the error was caught, so I was really stuck. The real problem is much more clear with a stack trace:
Traceback (most recent call last): File ".../django/core/management/base.py", line 88, in execute translation.activate('en-us') File ".../django/utils/translation/__init__.py", line 74, in activate return real_activate(language) File ".../django/utils/translation/__init__.py", line 44, in delayed_loader return g['real_%s' % caller](*args, **kwargs) File ".../django/utils/translation/trans_real.py", line 209, in activate _active[currentThread()] = translation(language) File ".../django/utils/translation/trans_real.py", line 198, in translation default_translation = _fetch(settings.LANGUAGE_CODE) File ".../django/utils/translation/trans_real.py", line 183, in _fetch app = __import__(appname, {}, {}, []) File ".../mailer/__init__.py", line 1, in <module> import mailer.admin File ".../mailer/admin.py", line 13, in <module> admin.site.register(Message, MessageAdmin) File ".../django/contrib/admin/sites.py", line 76, in register validate(admin_class, model) File ".../django/contrib/admin/validation.py", line 22, in validate models.get_apps() File ".../django/db/models/loading.py", line 103, in get_apps self._populate() File ".../django/db/models/loading.py", line 57, in _populate self.load_app(app_name, True) File ".../django/db/models/loading.py", line 73, in load_app mod = __import__(app_name, {}, {}, ['models']) File ".../retail/models.py", line 10, in <module> import tagging File ".../tagging/__init__.py", line 3, in <module> from tagging.managers import ModelTaggedItemManager, TagDescriptor File ".../tagging/managers.py", line 8, in <module> from tagging.models import Tag, TaggedItem File ".../tagging/models.py", line 16, in <module> from tagging import settings ImportError: cannot import name settings
Outputting a stack trace is really too much information. The reason all commands fail is that the translation is changed to en-us when executing a command, so settings must be imported which in turn loads models.
I think that a more general improvement could be made, but I think it's more important to minimise the pain for people switching to 1.0
I propose a try-catch around the import call in load_app, which instead would have given me this output:
$ ./manage.py test
Error: Failed to load models for retail, cannot import name settings in ../tagging/models.py line 16
Attachments (2)
Change History (10)
by , 16 years ago
Attachment: | 9120.load_app.py added |
---|
comment:1 by , 16 years ago
Triage Stage: | Unreviewed → Design decision needed |
---|
Can you please upload a real patch (see the contributing doc for guidelines) so we can figure out what you're changing here?
comment:2 by , 16 years ago
hvendelbo, why do you say that "Outputting a stack trace is really too much information"?
Here is a patch that helped me to solve the same problem (import error caused by my code,
occuring during translation.activate('en-us')
where import errors are captured).
I don't see why outputting the stack trace is really too much information.
by , 16 years ago
Attachment: | 20090423.diff added |
---|
comment:3 by , 15 years ago
Cc: | added |
---|
comment:4 by , 14 years ago
Severity: | → Normal |
---|---|
Type: | → New feature |
comment:5 by , 14 years ago
Easy pickings: | unset |
---|
comment:7 by , 12 years ago
Component: | Core (Other) → Database layer (models, ORM) |
---|
comment:8 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
This seems to be fixed in master, you get an informative exception if your models.py contains invalid code.
load_app method with better error reporting