#11667 closed New feature (duplicate)
Full traceback if import error before model validation
| Reported by: | jedie | Owned by: | nobody |
|---|---|---|---|
| Component: | Core (Management commands) | Version: | 1.1 |
| Severity: | Normal | Keywords: | |
| Cc: | django@…, riddell@…, klaasvanschelven@… | Triage Stage: | Accepted |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | yes | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
I had an import loop in a app model. If i call the management command "runserver", i get only a one line error message, whitch doesn't help to find the real error.
django.core.management.base.execute should display a read traceback. See patch.
Attachments (4)
Change History (19)
by , 16 years ago
| Attachment: | django_11667_patch.diff added |
|---|
comment:1 by , 16 years ago
| Cc: | added |
|---|---|
| Needs tests: | set |
comment:2 by , 16 years ago
| Triage Stage: | Unreviewed → Accepted |
|---|
comment:3 by , 16 years ago
django.core.management.base.BaseHandler.load_middleware will also "mask" some import errors. Add a separate patch, if settings.DEBUG is on, raise the original error instead of ImproperlyConfigured, so the user will get a helpfull traceback.
comment:4 by , 16 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
I had a similar issue when running tests. I would do a manage.py test and get an django.core.exceptions.ImproperlyConfigured: App with label <label> could not be found. The real culprit was an import loop. As jedie suggests, displaying the original ImportError would be helpful.
I'll attached a patch for the manage.py test case as django_11667_manage_test.diff.
comment:5 by , 16 years ago
| Cc: | added |
|---|
comment:6 by , 16 years ago
| Owner: | removed |
|---|---|
| Status: | assigned → new |
comment:7 by , 16 years ago
| Owner: | set to |
|---|
comment:8 by , 15 years ago
I agree that wrapping the exceptions makes debugging import errors very hard and would be Good Thing to improve with Django
I have on occasion replaced
raise ImproperlyConfigured('ImportError %s: %s' % (app, e.args[0]))
with just
raise
in template/loaders/app_directories.py line 24 (django 1.2.1) which allows me to see what module/file was trying to do the failing import when running manage.py test
A message like 'cannot import %s from %s line %d' from ImportError would help a lot, but that is more a python issue.
comment:9 by , 15 years ago
Any movement on this?
I can't count the number of times I've dived into the Django code and added a 'raise'. Of course, the proper solution would be simply to drop the associated try/catch block, since all it does is obfuscate things.
This can be rewritten:
206 if self.can_import_settings:
207 try:
208 from django.utils import translation
209 translation.activate('en-us')
210 except ImportError, e:
211 # If settings should be available, but aren't,
212 # raise the error and quit.
213 sys.stderr.write(smart_str(self.style.ERROR('Error: %s\n' % e)))
214 sys.exit(1)
I'll submit a patch in a sec.
by , 15 years ago
| Attachment: | remove_try_catch added |
|---|
A patch that drops the try/catch block altogether
comment:10 by , 15 years ago
| Cc: | added |
|---|
comment:11 by , 15 years ago
| Component: | django-admin.py runserver → Core (Management commands) |
|---|
comment:12 by , 15 years ago
| Severity: | → Normal |
|---|---|
| Type: | → New feature |
comment:14 by , 14 years ago
| Resolution: | → duplicate |
|---|---|
| Status: | new → closed |
I'm closing this ticket in favor of #16397 which reports the same problem (as far as I can tell) and has a more recent patch.
use traceback.format_exc()