Script subprocesses cannot be debugged

[anuraaga]

Currently, if a python script is executed directly as a subprocess by using a shebang, it isn't debugged.

This is clear from the code which is currently only checking the executable name for python and family.

debugpy/src/debugpy/_vendored/pydevd/_pydev_bundle/pydev_monkey.py

Line 283 in ea1dd9a

for name in _get_str_type_compatible(filename, ["python", "jython", "pypy"]):

Looking at pydevd logs, it exits with "Process is not python, returning." as expected from the code.

debugpy/src/debugpy/_vendored/pydevd/_pydev_bundle/pydev_monkey.py

Line 394 in ea1dd9a

pydev_log.debug("Process is not python, returning.")

Not simple, but IIUC fixing this means that it should open the file, check for a shebang, and replace the executable with the shebang line + script location. I'm uncertain if only patch_args needs to be updated with such logic or every caller of is_python.

Note I don't create the script myself but use project.scripts, and uv_build compiles the script wrapper when running uv sync. A manually shebanged file would naturally have the same issue though is easier for the user to replace with a python invocation - with a project.scripts, there is some awkwardness with it being in the .venv/bin directory, not cwd (I am using a multi-project workspace). As a workaround, I will probably still resolve the absolute path of the script and prepend python.

Environment data

Skipping since it's obvious from the code

Actual behavior

debugpy does not patch the subprocess args for a python script, causing debug to fail

Expected behavior

A python script subprocess can be debugged

Steps to reproduce:

1. Create a python script with a shebang
2. Create another script that invokes the script directly with subprocess.run, without python
3. Debug the launcher script with a breakpoint in the shebang script

My shebang script for a django project created by uv looks like

manage

#!/Users/anuraag/git/workspace/.venv/bin/python3
# -*- coding: utf-8 -*-
import sys
from sysadmin.manage import main
if __name__ == "__main__":
    if sys.argv[0].endswith("-script.pyw"):
        sys.argv[0] = sys.argv[0][:-11]
    elif sys.argv[0].endswith(".exe"):
        sys.argv[0] = sys.argv[0][:-4]
    sys.exit(main())

[rchiodo]

I wonder if this is what's required for #1894

[anuraaga]

I randomly noticed pytest-cov's implementation of subprocess instrumentation

https://pytest-cov.readthedocs.io/en/latest/subprocess-support.html

It uses a path file to force logic on startup - now it reminds me of how OpenTelemetry works too. Would it make sense to migrate debugpy's instrumentation to such an approach? Maybe it's more generalizable than arg processing. Just a random idea.

[rchiodo]

Oh using a pth file is pretty clever. That's an interesting idea. Combining environment variables and a pth file. I guess we could delete the pth file after the debug session was done. Might require write access that we don't have, although that could probably be worked around by adding something to PYTHONPATH. But using pth files for code injection is cool :)

[anuraaga]

Thanks @rchiodo - the way I imagined it is that current usage through IDEs, which AFAIK inject debugpy itself into the environment, would take care of injecting the pth and uninjecting it along with the rest of debugpy, probably with no real change from how they work today. For CLI usage, i.e. installing debugpy into the environment with a package manager, the pth file would just be there permanently, similarly to pytest or otel, and a noop without proper env var set.