Running Run Commands for Local Remote Debugging
by Troy Topnik

Troy Topnik, July 31, 2009

The title is intentional. I'll explain later. Once you've started
abusing the language, you might as well kick it to the curb.

Once in a while, a question comes in to ActiveState support that
exposes a better way of doing something. A user recently contacted us
about debugging Django applications, and I directed him to this
post by Todd Whiteman

I suggested trying the second option mentioned: running the Django
server through pydbgp. The relevant command is basically:

    $ /path-to-komodo-install/lib/support/dbgp/bin/pydbgp -d \
    localhost:9000 runserver --noreload

Using the default Komodo paths on Windows, the command would end up
looking like this:

    C:\Django\MyProject>python "Program Files\ActiveState Komodo IDE 5\lib\support\dbgp\bin\" localhost:9000 runserver --noreload

Long enough for ya? This is assuming 'python' is on the system path
and that you're in the root directory of your Django project - so the
command could end up being longer still.

This user wondered, quite understandably, why he couldn't just start
the debugger using the "Go/Continue Debugging" or "Step In" buttons.
This isn't actually possible when debugging in frameworks like Django or
Rails, and the reason why involves clarifying something that is a little
murky to a lot of new Komodo users.

Local vs. Remote debugging

When you click "Go/Continue Debugging" or "Step In" in Komodo IDE,
you're doing "local" debugging. Komodo takes the current file and passes
it to the appropriate debugger for the language. Debugging starts in the
file you have open, and everything happens on the local machine.

What we call "remote debugging" involves initiating the debugging
session outside of Komodo, even if the debugger is running on the same
. This might seem counter-intuitive if your normal dev
environment has you running a web server on your local machine, but as
far as Komodo's debug listener is concerned, it's an external connection.

Remote debugging with any of the supported languages is a
little more complicated to set up
, but it is extremely flexible and
allows you to debug web applications (and web framework
applications) while actually using them in a browser.

So, when you want to debug a framework application, running any one of
the files through the debugger independently is not going to tell you
much. In fact it probably won't run at all because it's not meant to be
run independently by the interpreter. We need to debug the application
in the context of the server it's running in, so we run the whole
framework server through the debugger.

Run commands

Since I've already copped to using the term "remote" ambiguously, I
can now confess to "nouning" the phrase "run command". Komodo's "Run
Commands..." feature allows you to run terminal/console commands without
having to jump to the command-line. Since you can save these commands in
toolboxes and projects, we needed a name for the commands in their saved
state so we could document the feature. In retrospect, we should have
called them "Saved Commands" or something else less confusing, but
somehow "Run Commands" stuck. Sorry about that.

Anyway, they're very good at solving problems like the one above,
because they can use interpolation
- basically variables available within Komodo. We can use
these in the folloing alternative to the command above:

     %(python) %(path:supportDir)\dbgp\bin\ -d \
     %(debugger:port):%(debugger:address) runserver --noreload

Note especially the "%(debugger:port)" shortcut. Using this, you can
set the debugger connection preferences to use "a system-provided free
port". This gets around a known issue
where the operating system doesn't release the configured port
in a timely way after a terminated debugging session. The standard
work-around solution for this is to use the debugger
, but this is much easier.

Right-click in your project or toolbox and "Add|New Command..." to
bring up the Run Command dialog box. Setting up the command above might
look something like this:

Django Debugging Run Command

Under "Advanced Options" (click the More button to see them) you can
set "Start in:" to:

  • %D - the directory of the current file in the buffer (probably
    not that useful in this case)
  • %p - the base directory of your project (i.e. where the .kpf
    file is saved ). This should work if you are using a "live
  • The full path to the app's base directory. This is probably the
    most useful way to set it if you're not using a live

You can choose to see the output to the Command Output Tab or open a
new console. You can also setup any environment variables you might
need; these are in addition to any system environment variables, and any
you may have set up globally in Komodo under "Preferences|Environment".

Once you've saved the command you can set a key binding for it,
and/or add it to a custom toolbar. After that, starting a "remote"
debugging session for your app is just a keystroke or click away.

Subscribe to ActiveState Blogs by Email

Share this post:

About the Author: RSS

As ActiveState's Technical Product Manager for Stackato, Troy Topnik is responsible for defining and prioritizing the product roadmap to build the best cloud platform for deploying applications. Since joining ActiveState in 2001, he has held roles in Technical Support, Training, and Technical Writing. He believes in documentation-driven development as a pragmatic path to a better user experience.