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 manage.py 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\pydbgp.py" localhost:9000 manage.py 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 machine. 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 shortcuts – basically variables available within Komodo. We can use these in the folloing alternative to the command above:

     %(python) %(path:supportDir)\dbgp\bin\pydbgp.py -d \
     %(debugger:port):%(debugger:address) manage.py 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 proxy, 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:
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 project“
• 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 project.

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.
Title photo courtesy of Jeremy Lapak on Unsplash.