Debugging Django apps

Posted by thirteenpixels on 2007-01-24 14:04
Forums: Komodo Beta | OS: All / Any

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?

toddw
ActiveState Staff
Fri, 2007-01-26 21:11

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:

export PYTHONPATH=/opt/Komodo/Komodo-IDE-6.1.0/lib/support/dbgp/pythonlib
python manage.py runserver

Import dbgp and make break statements in your python code:

import dbgp.client
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 --noreload

For 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 --nothreading

Note: 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!

grahamu | Tue, 2007-02-27 16:10

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 --noreload

I 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!

codepete | Thu, 2012-07-12 08:23

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?

toddw
ActiveState Staff
Fri, 2012-07-13 15:58

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

thirteenpixels | Sat, 2007-01-27 05:55

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.

toddw
ActiveState Staff
Tue, 2007-02-27 18:19

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

TailOfTheSun | Sun, 2007-03-04 22:54

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?

toddw
ActiveState Staff
Thu, 2007-03-08 14:18

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.

toddw
ActiveState Staff
Thu, 2007-03-08 19:30

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:

import dbgp.client
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

TailOfTheSun | Wed, 2007-04-25 17:32

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?

grahamu | Tue, 2008-10-28 22:07

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 --noreload

and 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!

grahamu | Wed, 2008-10-29 01:04

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

toddw
ActiveState Staff
Thu, 2008-10-30 11:04

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

Ant | Mon, 2007-04-16 01:18

Interest example from http://www.cetus.com.ua/research/example/djqt1.html

Create Django project, app and model:

django-admin.py startproject djqt1
cd djqt1 && ./manage.py startapp polls

Editted polls/models.py:

from django.db import models

# 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_ENGINE = 'mysql'           # 'postgresql', 'mysql', 'sqlite3' or 'ado_mssql'.
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:

export DJANGO_SETTINGS_MODULE=settings
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:

# -*- coding: utf-8 -*-

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()

toddw
ActiveState Staff
Wed, 2007-04-25 17:54

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:

try {
    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

TailOfTheSun | Wed, 2007-04-25 19:20

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?

toddw
ActiveState Staff
Thu, 2007-04-26 10:04

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

etatsevitca_mai... | Thu, 2008-07-17 04:13

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:

class Break(object):
    """
    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!

toddw
ActiveState Staff
Thu, 2008-07-17 10:48

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.

dangtangy | Wed, 2009-08-19 17:39

I've found you can also use it really successfully with
manage.py test myapp too