Can Windows Komodo point at Python3 on WSL2?

Does anyone know if it’s possible to point Komodo’s debugger (running on Windows) at a python3 interpreter running on Ubuntu under Windows Subsystem for Linux? And if so, how to do it?

I need to use some python libraries that aren’t compatible with Windows python but that I have installed on Ubuntu on WSL2. I know there is a Komodo for linux, but I haven’t had any luck getting a GUI working on the Ubuntu side.

I’m not sure if you can point a Windows install of Komodo at a WSL Python interpreter but you could certain set remote debugging and launch the process from a WSL terminal: https://docs.activestate.com/komodo/12/manual/debugpython.html#using-the-python-remote-debugger

OK. I have it to the point where I can successfully run pydbgp --help. Now I am kind of bewildered by instructions for getting it to debug.

Part of the problem is that the package has all kinds of versions of the files, pydbgp, pydbgp.py, py3_dbgp, py3_dbgp.py. I think the ones with .py are intended for windows and without for linux, but I’m not certain about that. The docs are written assuming I use the ones with the .py extension.

Also there seems to be an option for running the remote debugger with and without a proxy, but how do I determine which to use?

Finally I don’t understand how Komodo gets a copy of the file being debugged, and thus how I would set a breakpoint to do actual debugging.

Anything you could do to enlighten me about this would be appreciated.

Morning @DryHeat122,

I get the feeling you’re overthinking things. Are you hitting a specific issue? Have you gone through the docs and it’s not working? Please clarify where you’re at, what you’ve tried, what you expect to happen and what is actually happening.

Re which file to use: You should be able to just follow the docs. The docs tell you which files to use. You shouldn’t need to guess. Is there a specific issue you’re hitting or are you just worried you might be using the wrong file?

Re proxy: if you don’t know what a proxy is or if you’re using one, I think it’s fair to assume you’re not using one. In your context, you’re not likely to be using a proxy on localhost.

Re how Komodo gets the file: The file is transferred to Komodo along with all the other debugging information over TCP.

So again, please clarify your situation:

  • Share the commands you used for setting up
  • Share the command you’re running to start the debugger
  • Tell me what you’ve done and what you expect to happen, then tell me what actually happens.

That should give me the information I need to help.

  • Carey

OK I followed the exact instructions in the doc:

$ python3 -S py3_dbgp.py -d localhost:9000 compare-to-empirical.py
Traceback (most recent call last):
File “py3_dbgp.py”, line 105, in
import dbgp.client
ModuleNotFoundError: No module named ‘dbgp’

However, when I start python3 and enter import py3_dbgp.py, it finds and imports it fine.

Sounds like you skipped step 2:

Set up your Python installation so the dbgp Python package is on your PythonPath. You can do this by copying the dbgp directory to the site-packages directory of your Python installation. Alternatively, you can copy the dbgp directory to a convenient location, and then add that directory to your PYTHONPATH environment variable.

Make sure you’ve read and followed all the instructions in the docs.

No, I did that step by copying the dbgp directory to the site-packages directory. As I said, python3 can successfully import the package when I use the command line interface. Just to be sure I ran the following script (which does the same thing as the command in item 2 of the docs but is python3 syntax):

import dbgp.client
print("OK")

And it prints OK when run.

Also py3_dbgp --help, a test in item 4 of the docs, gives the help listing as it should. So everything is working through “Invoking the Python Remote Debugger.”

Given all of that, it’s a mystery to me why the py3_dbgp.py script can’t find it. I checked line 105 of the script and it’s exactly what I used in the test script above.

I decided to try the within-script method of invoking the debugger that is mentioned in the docs:

from dbgp.client import brk
def foo():
    print "Hello, World!"
    brk(host="**mybox**", port=**9000**)
    print "Goodbye."

But there are problems with that script. First, like the others it doesn’t use python3 syntax. Second I think (but am not sure) it needs to import dbgp.client before importing brk from it. Third, it will never run because it defines a method but never runs it. So I ran this:

import dbgp.client                                                                                                                                                                      
from dbgp.client import brk                                                                                                                                                             
def foo():                                                                                                                                                                                  
    print("Hello, World!")                                                                                                                                                                  
    brk(host="localhost", port=9000)                                                                                                                                                        
    print("Goodbye.")                                                                                                                                                                   
foo()      

Running this, I got dbgpSocket: error: unable to connect to remote host at localhost:9000 Thought I was onto something, so I set a rule to allow TCP traffic on port 9000 on my windows firewall (Kaspersky), but I still get the same error. AFAIK the firewall is not enable in the WSL2 Ubuntu, so I don’t know what could be blocking things.

This might explain my problems:

Unlike WSL1, you cannot use 127.0.0.1 or localhost to connect back to Windows in WSL2. When you start WSL2, it gets its own IP address and works more like a Hyper-V virtual machine. Microsoft seems to be working on changing this behavior and planning on supporting shared loopback addresses just like WSL1 but it’s not yet happened.

@DryHeat122 try the IP address of the Windows part of your computer. I don’t have any experience using WSL so I don’t know if the Linux layer mocks it’s own network interfaces or not but if it does then hopefully the Windows half has it’s own IP that you can use to connect to it.

The command if ipconfig in Windows CMD to see your IP.