Opened 10 years ago

Closed 8 years ago

#3420 closed (fixed)

manage.py validate [app] should display line numbers for syntax errors

Reported by: Paul Collier Owned by: nobody
Component: Core (Management commands) Version: master
Severity: Keywords:
Cc: egmanoj@… Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: yes
Easy pickings: UI/UX:

Description

When running validate for an app whose models.py file or any file it includes contains a error (most commonly syntax or function argument errors), the listing does not display the offending line/line number/file. This can make deciphering the source of the error difficult--or simply inconvenient, as the info can be obtained by attempting to import the offending model.

Attachments (1)

db.models.loading.diff (1.2 KB) - added by egmanoj@… 10 years ago.
Patch for displaying details such as file name, line number etc. for import errors that occur during 'validate'.

Download all attachments as: .zip

Change History (8)

comment:1 Changed 10 years ago by Simon G. <dev@…>

Triage Stage: UnreviewedDesign decision needed

comment:2 Changed 10 years ago by Malcolm Tredinnick

Triage Stage: Design decision neededAccepted

This can't hurt and looks useful. Moving to "accepted" so that somebody can go to town and write a patch.

Changed 10 years ago by egmanoj@…

Attachment: db.models.loading.diff added

Patch for displaying details such as file name, line number etc. for import errors that occur during 'validate'.

comment:3 Changed 10 years ago by egmanoj@…

Has patch: set

Added patch.
Please note that non import ("custom") validation errors are still not handled.
For e.g. CharField requires maxlength property to be non-zero. In such cases the error messages will not contain file name, line number etc.

comment:4 Changed 10 years ago by egmanoj@…

Cc: egmanoj@… added

comment:5 Changed 9 years ago by mcroydon

Patch needs improvement: set

django/db/models/loading.py has been refactored and this patch no longer applies.

comment:6 Changed 9 years ago by Adam Vandenberg

This doesn't look needed anymore; the refactoring to use an cache no longer does a try/catch around the dynamic imports, so any import-generated exceptions are dumped to the console already.

comment:7 Changed 8 years ago by Adrian Holovaty

Resolution: fixed
Status: newclosed

Couldn't reproduce the problem...Looks like it's been fixed, per the comments above.

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