Treat mapped files as my code

[mforkel]

I would like to suggest that files in or below a directory included in the path mappings of a launch configuration should always be considered my code. Or, in order not to deviate from current behavior, there could be a setting to declare them my code, e.g. mappedMyCode.

Rationale: The user will likely specify path mappings only for his/her own code and expect to use breakpoints in those files. Evaluating path mapping is more specific than setting justMyCode to true, which adds many (library) files. Specifying paths to own code both in mappings and in include rules (once available) is inefficient and error prone.

In my case, I wanted to debug proprietary Python code that was distributed and installed as a regular Debian package, i.e. below /usr/lib/python*/dist-packages. It took me a while to figure out that this directory is on pydevd's LIBRARY_PATHS and that I would have to set justMyCode to false.

[karthiknadig]

@mforkel You can include rules in you launch json config to get this result.

        {
            "name": "Python: Current File",
            "type": "python",
            "request": "launch",
            "program": "${file}",
            "console": "integratedTerminal",
            "rules": [
                 {"path": "<glob pattern> or <path>", "include": true },
                 {"path": "<glob pattern> or <path>", "include": true },
            ]
        }

[mforkel]

You can include rules in you launch json config to get this result.

Yes, but in cases like mine, with a multi-root workspace, a number of path mappings, and many launch configurations, that is quite a bit of redundant input and somewhat hard to keep consistent. But even in simpler cases, I think it is confusing that something for which I have specified a path mapping is not considered my code.

This might be another issue, but is there something like a launch configuration template that other configurations can refer to or include to avoid, e.g. for path mappings.

[int19h]

Can be done on debugpy side by generating "rules" before passing it on to pydevd.

[judej]

Thank you for the report. Given that there is workaround and our current resources are working on the Python 3.12 debugger, we will not be fixing this issues in the pre Python 3.12 debugger.