- Community |
- Code |
- Docs |
- Downloads ▼ |
- more ▼
Debugging Django apps
Posted by thirteenpixels
on 2007-01-24 14:04
I did a quick search on the web and these forums and I can't see anyone discussing how to debug Django apps with Komodo. Has anyone had any success/failures they can share?
- Login to post comments
Yes it is possible using "Python Remote Debugging" - docs on this feature are here:
http://docs.activestate.com/komodo/7.0/debugpython.html#Using_the_Python...
You have two ways of going about remote debugging:
1) Remote debugging with in-code breakpoints
Ensure Komodo's python dbgp is on your pythonpath and then start your django server, example below:
python manage.py runserver
Import dbgp and make break statements in your python code:
from django.db import models
class Poll(models.Model):
question = models.CharField(maxlength=200)
pub_date = models.DateTimeField('date published')
def was_published_today(self):
# Make a break statement, specify Komodo's debugger address
dbgp.client.brk(host="localhost", port=49983)
return self.pub_date.date() == datetime.date.today()
was_published_today.short_description = 'Published today?'
When the code is executed, Komodo will be contacted and will break at the given location.
2) Remote debugging of the whole server - through pydbgp
Run the server through dbgp. Note: This requires running with the "--noreload" option, otherwise the process will fork and no debugging will occur, but you lose the automatic reloading this way.
/path-to-komodo-install/lib/support/dbgp/bin/pydbgp -d localhost:9000 manage.py runserver --noreloadFor Django 1.4 and above, it now has threading enabled by default, so you may wish to run Django without threads using this command line:
/path-to-komodo-install/lib/support/dbgp/bin/pydbgp -d localhost:9000 manage.py runserver --noreload --nothreadingNote: Change "path-to-komodo-install" to be your Komodo install location, change "localhost" to be the machine Komodo is running on (it can be on a different machine) and change 9000 to be the debug port Komodo is set to listen to, you can find this debugger port by looking at Komodo's menu "Debug->Listener Status".
This connects to the Komodo debugger and then starts the Django server.
You can set breakpoints by opening your python Django project files in Komodo and then placing a breakpoint at the location you wish to stop.
Let me know if you have any problems or suggestions on this.
Cheers!
You might want to revise option 2) above to something like this:
/path-to-komodo-install/lib/support/dbgp/bin/pydbgp -d localhost:9000 manage.py runserver --noreloadI suggest this for three reasons:
1. On my system /opt/Komodo/Komodo-IDE-4.0.0 does not exist so this part could be more generic.
2. The remainder of the path: "/lib/support/dbgp/" does not contain pydbgp.py.
3. The default port where the IDE listens for debugger connections is 9000.
I absolutely love the debugging facility for Django, it makes learning Django internals so much easier.
Graham
PS Thanks for the good presentation at PyCon 2007!
Are you guys planning to fix the multi-threading issue with Django 1.4? If so, how long do you think before you guys will have a fix out?
The issue is logged here:
http://bugs.activestate.com/show_bug.cgi?id=94582
More digging into this problem will be require before an ETA can be given. Add yourself to the bug cc-list and you'll automatically get notified of any progress/changes.
Cheers,
Todd
Thanks! This works great! This should be added to the documentation as I'm sure other people would find it very useful too.
Thanks again for your help.
Thanks for suggestions, I've updated the message accordingly.
Good to talk to you at PyCon and I hope Subversion is now working correctly inside your Komodo, if not let me know.
Cheers,
Todd
The debugger will break the first time, but after that, it stops hitting my breakpoints. It also no longer allows me to delete the original breakpoint it stopped at. Is anyone else having this problem?
I noticed a similar problem with another python app, which Shane Caraveo is looking at.
I'll update again once we have more info on this.
This is due to a threading feature/buglet.
To workaround, ensure the Komodo dbgp code is the first code that gets run by the python process, as this will properly setup the threading hooks to properly enable threaded debugging with Komodo.
You can do this by adding the following lines to the top of the file manage.py:
dbgp.client.brk(host="localhost", port=9000)
This method is also discussed in the TurboGears debugging forum message:
http://support.activestate.com/forum-topic/debugging-turbogears
Thanks for the advice ToddW. Unfortunately, I am having the same problems still even after adding those lines to the top of manage.py. Is it because I am using Python 2.5? I noticed inside the dbgp package, there were _client23.so and _client24.so files, but didn't know if those numbers referred to the Python version. Also, does it matter that I am not using the Python installer from ActiveState.com?
Hi Todd,
For some unknown reason debugging stopped working in one of my projects and I don't understand what could have caused the problem. For project A debugging works fine, I invoke a Windows batch file which runs:
python -S "<path-to-komodo>\lib\support\dbgp\bin\pydbgp.py" -d localhost:9000 manage.py runserver --noreloadand the IDE stops on breakpoints, etc.
In project B I run the same batch file, see the same breakpoint in manage.py (although manage.py doesn't show up in the editor like it does in project A), hit Run and then see the Django output in the debug window. However breakpoints (which do show up in the list) are never hit.
Could this be an issue with the URI mapping stuff? I never did really understand that. Maybe I messed up something with the URI? Is there a way to view or reset the URI mappings? Any other ideas? The forum doesn't seem to address this issue.
Thanks!
Todd,
I finally found the mapped URI preferences pane and found a bad URI for the problem project. After deleting that line and inserting a proper mapping debugging works fine.
Graham
Hi Graham,
That is good that you've got it working again, thanks for updating the forum.
There was bug in Komodo 4.4.1 that was creating bad mapped URIs on projects:
http://bugs.activestate.com/show_bug.cgi?id=78847
which could have been the cause of this problem.
Cheers,
Todd
Interest example from http://www.cetus.com.ua/research/example/djqt1.html
Create Django project, app and model:
cd djqt1 && ./manage.py startapp polls
Editted polls/models.py:
# Create your models here.
class Poll(models.Model):
question = models.CharField(maxlength=200)
pub_date = models.DateTimeField('date published')
Make settings in settings.py:
DATABASE_NAME = 'djangodb' # Or path to database file if using sqlite3.
DATABASE_USER = 'cetus' # Not used with sqlite3.
ROOT_URLCONF = 'djqt1.urls'
INSTALLED_APPS = (
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.sites',
'djqt1.polls',
)
Create and testing database:
echo "create database djangodb" | mysql
./manage.py install polls
python
>>> from poll.models import Poll
>>> from datetime import datetime
>>> p = Poll(0,"Example question",datetime.now());
>>> print p.question
>>>Example question
Create Qt application with Django interface:
from form1 import *
from datetime import datetime
from polls.models import Poll
class Form1Impl(Form1):
def __init__(self):
Form1.__init__(self)
self.connect(self.pushButton,SIGNAL("pressed()"),self.SlotInsert)
self.Select()
def Select(self):
p = Poll.objects.all()
self.table.setNumRows(len(p))
for i in range(len(p)):
self.table.setText(i,0,p[i].question)
self.table.setText(i,1,str(p[i].pub_date))
def SlotInsert(self):
p = Poll(0,question=self.lineEditName.text(),pub_date=datetime.now())
p.save()
self.Select()
I'd update to Komodo IDE 4.0.3 if possible, as there were some bugfixes to the dbgp codebase.
No, you do not need an ActivePython build, the Komodo debugger should work with the regular python builds from python.org.
If there is no matching version of Komodo's dbgp _clientXY.so, then it falls back to a python "client.py" version (it's just slower than using a compiled module). Note: In Komodo 4.0.3 there is now a _client25.so, so this should not matter then anyway.
You might want to try running through pydbgp, here is neat little JavaScript macro that I added to my Komodo toolbox/project for running through pydbgp (though you will need to update the paths and path separator), just add to your project and double click to debug:
var koDirs = Components.classes["@activestate.com/koDirs;1"].getService(Components.interfaces.koIDirs);
// Get the location of pydbgp python script
var pydbgp = koDirs.binDBGPDir + "/pydbgp";
Run_RunCommand(window,
"python " + pydbgp + " -d localhost:%(debugger:port) manage.py runserver --noreload 8880",
"%p", null, false, false, true, "new-console");
} catch(ex) {
alert(ex);
}
Let me know how it goes.
Cheers,
Todd
Ah... Komodo 4.0.3 did the trick. Thanks a lot!
BTW, sometimes when I toggle breakpoints when the program is running, it takes a few seconds before, and sometimes I cannot remove the breakpoint until I restart the application. Is this a known issue?
Good to hear it's working better now.
Yes, there are two known bugs regarding the breakpoint handling with Python in Komodo, see:
http://bugs.activestate.com/show_bug.cgi?id=67169
http://bugs.activestate.com/show_bug.cgi?id=57057
Add yourself to the cc list on the bugs to be notified when they are fixed and to see fixes as they become available.
Cheers,
Todd
If you want to use the django development server with a break at each request (like with xdebug), the cleanest way is to create a middleware.
For example:
"""
Middleware that sends a break using dbgp.
"""
def process_request(self, request):
import dbgp.client
dbgp.client.brk(host="localhost", port=9000)
Feel free to refer to the documentation: http://www.djangoproject.com/documentation/middleware/
Spoiler: all you have to do is include your middleware class to settings.py.
Note that i use vim and its dbgp extension avalaible on http://www.vim.org/scripts/script.php?script_id=1929 and that it works very fine!
Thanks for the great job on the dbgp python module BTW!
That looks really promising... I always find it a pain to have to insert break statements manually.
XDebug allows you to activate debugging through the GET/POST parameters, I guess this is would also be possible to do through this middleware? Which would make enabling/disabling of debugging a snap with the Firefox XDebug extension
Thanks for the info.
I've found you can also use it really successfully with
manage.py test myapptoo