Overview

Overview

django-viewtools provides a number of management commands for debugging views.

There are a number of flags that can be used when calling the view

-d, --debug: This sets settings.DEBUG to True before calling the
view. This allows you to retrieve the content from a view in production when settings.DEBUG is on
-n, --no-debug: This sets settings.DEBUG to False, handy to see what
will happen if DEBUG is turned off.
--pdb: This starts PDB before the request is handled. Great for when
you have a traceback email and want to set a breakpoint where it occurs.
--pm: This fires up PDB's post_mortum when an error occurs in the
process of calling a view.
--profile: This dumps a hotshot profile file to the location specified
for profiling the performance of a view.

-q, --quiet: Don't output the response of the view

-m, --mute: Turn off output through stdout and stderr, handy for noisy
views with print statements everywhere.

Example

So you have a traceback that gives you the following:

File "/home/eric/Projects/django/env/django-1.0.2/lib/python2.5/site-packages/viewtools/views.py", line 4, in py_error
  raise ValueError("This is an error")

And you don't know why it's happening. Even worse, it's only happening on your production server.

Before django-viewtools, you only had one option in this scenario, edit your production code, put some print statements or forced assertion errors to peek into the code to see the problem.

django-viewtools makes things a lot easier:

(django-1.0.2)eric@knoxpy:~/Projects/django/projects/viewtooltest$ ./manage.py viewtools --pdb /py_error/
> /home/eric/Projects/django/env/django-1.0.2/lib/python2.5/site-packages/viewtools/management/commands/viewtools.py(135)call_view()
-> try:
(Pdb) break /home/eric/Projects/django/env/django-1.0.2/lib/python2.5/site-packages/viewtools/views.py:4
Breakpoint 1 at /home/eric/Projects/django/env/django-1.0.2/lib/python2.5/site-packages/viewtools/views.py:4
(Pdb) continue
> /home/eric/Projects/django/env/django-1.0.2/lib/python2.5/site-packages/viewtools/views.py(4)py_error()
-> raise ValueError("This is an error")
(Pdb) list
  1   from django.db import connection as db
  2
  3   def py_error(request):
  4 B->       raise ValueError("This is an error")
  5
  6           def db_error(request):
  7               c = db.cursor()
  8                   c.execute("select * from asotuhaosetuhaosethuasote")
[EOF]
(Pdb) print request
<WSGIRequest
GET:<QueryDict: {}>,
POST:<QueryDict: {}>,
COOKIES:{},
META:{'CONTENT_TYPE': 'text/html; charset=utf-8',
 'HTTP_COOKIE': <SimpleCookie: >,
 'PATH_INFO': u'/py_error/',
 'QUERY_STRING': '',
 'REQUEST_METHOD': 'GET',
 'SCRIPT_NAME': u'',
 'SERVER_NAME': 'testserver',
 'SERVER_PORT': '80',
 'SERVER_PROTOCOL': 'HTTP/1.1',
 'wsgi.errors': <cStringIO.StringO object at 0x10a68b8>,
 'wsgi.input': <django.test.client.FakePayload object at 0x10ec150>,
 'wsgi.multiprocess': True,
 'wsgi.multithread': False,
 'wsgi.run_once': False,
 'wsgi.url_scheme': 'http',
 'wsgi.version': (1, 0)}>
(Pdb)

Isn't that just great? I can see all the local variables in the view.