Opened 14 years ago
Closed 13 years ago
#15132 closed Uncategorized (wontfix)
The runserver command is missing --verbosity and --traceback
Reported by: | cardonbj | Owned by: | nobody |
---|---|---|---|
Component: | django-admin.py runserver | Version: | 1.2 |
Severity: | Normal | Keywords: | |
Cc: | zeraien | Triage Stage: | Unreviewed |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
I've done some searching and don't think this is a duplicate. Basically, the documentation and a lot of other things talk about every manage command having access to both --verbosity and --traceback, however doing a manage.py runserver --traceback has no effect, neither does manage.py runserver --verbosity=2.
I think traceback in particular is necessary as anyone who is developing a RPC system using SOAP, AJAX, REST or any other four letter word can't see the literal exception that is taking place.
Change History (4)
comment:1 by , 14 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
comment:2 by , 14 years ago
Surely it should do what it used to do in the past? According to the discussion here, it existed in an old SVN revision:
So if it could have worked once, can't it be made to work again?
(I've got a similar problem to the OP -- this is something I would dearly like to reappear)
comment:3 by , 13 years ago
Cc: | added |
---|---|
Easy pickings: | unset |
Resolution: | wontfix |
Severity: | → Normal |
Status: | closed → reopened |
Type: | → Uncategorized |
UI/UX: | unset |
There is a extension called django-extensions which has a runserver_plus command, which runs a dev server with werkzeug debugger, but that is beside the point. The main point is that this runserver_plus command prints out a traceback of every exception thrown by the code.
This is very useful as the OP said in developing websites that use a lot of AJAX or RPC requests, since having to manually read HTML when scanning failed requests is bullocks.
At the very least there should be an is_ajax check that will return 500 errors with tracebacks in plain text for any ajax request, rather than full HTML that it is now.
comment:4 by , 13 years ago
Resolution: | → wontfix |
---|---|
Status: | reopened → closed |
Please don't reopen tickets closed as "wontfix" by core developers. If you disagree with the fact that the ticket was closed, I encourage you to take the discussion to the django-developers mailing list. For more information, see the contributing guide in the documentation.
Regarding the template for errors in AJAX queries, the problem is already reported in #10841, #16190 and #16227.
Marking wontfix because I'm having difficulty thinking of what either option would actually do.
I can't think of a change we could make that would increase the verbosity of the development server -- it already reports every request that hits it.
As for tracebacks -- server errors are caught and returned as 500s, but that's at a layer of abstraction deeper than the runserver command.
I'm happy to entertain the general principle of "more debug is better", but in this case, I would need to see the specific change that is being proposed.