When enable_attach is at the top of the file, the daemon process doesn't actually start. The reason for this is that DaemonRunner spawns a separate background process, and then enable_attach in that background process tries to open a port for debug server, using the same port number as the foreground process that is spawning it. Since foreground process already has debug server running on that port, hijacking it ends up crashing that process. We should probably have some better diagnostics for when it happens to make it clearer.

Calling enable_attach from inside run is the proper approach in this case, and it should work. Can you please verify that the top frame in the call stack is indeed within your module (and not, say, within the debug server code)?

Yes. Here is the callstack:

run in test Python

_start in runner    Python
do_action in runner Python
test module Python

I've attached the python file that I've used to reproduce this issue. My steps are this:

1. From linux, run "python ./test.py start".
2. In studio, set a breakpoint on the "testVar = 1" line.
3. Go to DEBUG -> Attach to process.... Choose Python remote debugging (unsecured). For qualifier, type in the server name and press enter. Double-click on the python process that shows up in the available processes.
4. A new tab opens titled "No Source Available" which looks like the first screen shot I submitted.
5. Click on the "test.py" tab. Note that the breakpoint does not appear to be activated.
6. Press F10. The "No Source Available" tab reopens.
7. Go back to the test.py tab and mouse-hover over testVar.
   Results: It correctly shows the contents of the variable, allows stepping and continuing, and the call stack is as follows:
   -> run in module test
   _start in module runner
   do_action in module runner
   test module
   However, there is no indication of what line the debugger is on or that the breakpoint has been hit.