Unexpected configuration merging behavior for justMyCode debugging option

[tboddyspargo]

In #139, many people have reported being unable to use justMyCode as expected. While there is a workaround in the linked comment, I believe it ultimately stems from the global debugpy.debugJustMyCode overwriting the launch configuration option, which I think is unexpected.

I had always been relying on the launch-configuration-level setting of justMyCode being set to false to be sufficient. Is the extension perhaps not merging the different levels of configs as expected and leading to the default debugpy.debugJustMyCode to trump the launch-configuration-level justMyCode when specified in .code-workspace files?

Originally posted by @tboddyspargo in #139

I wanted to repost this here in an effort to specifically focus on the question of configuration merging behavior.

I expect the repro to be something like:

1. Specify a python special purpose file or test debug configuration (with "justMyCode": false) in the launch configuration of a .code-workspace file.
2. Open that workspace and debug a python script using that launch configuration.
3. Try to step into library code using the debugger
   • Repeat this step, since the repro steps in Debugger: setting "justMyCode": false does not work in a Python 3.10 venv #139 (comment) sometimes indicate that the "first time" succeeds and subsequent ones do not.
4. Based on my previous experience and the other reports in Debugger: setting "justMyCode": false does not work in a Python 3.10 venv #139, I expect this to not go into library code during the "subsequent" debug sessions (frame skipped message?)

However I also think that, even without repro-ing, it may be reasonable to re-examine the config merging behavior of debugpy.debugJustMyCode with workspace-level launch configuration settings to definitively debug the root cause hypothesis here or confirm it.

[eleanorjboyd]

Thank you for your detailed investigation! @rchiodo thoughts here?

[rchiodo]

Sorry but I don't know how the extension merges settings, but you can tell if the correct setting was passed by turning on debug logging:
https://github.com/microsoft/debugpy/wiki/Enable-debugger-logs

That should output a log with the settings passed to debugpy when it starts. Something like this should show up in the log (debug-adapter-.log):

D+00001.359: Client[1] --> {
                 "seq": 2,
                 "type": "request",
                 "command": "launch",
                 "arguments": {
                     "name": "Python Debugger: Current File",
                     "type": "debugpy",
                     "request": "launch",
                     "program": "C:\\Users\\rchiodo\\source\\testing\\test_pylance\\test_debuglaunch.py",
                     "console": "integratedTerminal",
                     "subProcess": true,
                     "logToFile": true,
                     "__configurationTarget": 6,
                     "python": "c:\\Users\\rchiodo\\source\\testing\\test_pylance\\.venv313\\Scripts\\python.exe",
                     "debugAdapterPython": "c:\\Users\\rchiodo\\source\\testing\\test_pylance\\.venv313\\Scripts\\python.exe",
                     "debugLauncherPython": "c:\\Users\\rchiodo\\source\\testing\\test_pylance\\.venv313\\Scripts\\python.exe",
                     "clientOS": "windows",
                     "cwd": "c:\\Users\\rchiodo\\source\\testing\\test_pylance",
                     "envFile": "c:\\Users\\rchiodo\\source\\testing\\test_pylance/.env",
                     "env": {
                         "PYTHONIOENCODING": "UTF-8",
                         "PYTHONUNBUFFERED": "1"
                     },
                     "stopOnEntry": false,
                     "showReturnValue": true,
                     "internalConsoleOptions": "neverOpen",
                     "debugOptions": [
                         "ShowReturnValue",
                         "Multiprocess",
                         "FixFilePathCase"
                     ],
                     "justMyCode": false, <-- This is what debugpy is using. Not sure how this gets here, but somebody else is merging the values.
                     "workspaceFolder": "c:\\Users\\rchiodo\\source\\testing\\test_pylance",
                     "__sessionId": "b192b003-1b42-457a-93f9-4dc8e839dd9c"
                 }
             }

That's the launch request in the DAP:
https://microsoft.github.io/debug-adapter-protocol/specification#Requests_Launch

[eleanorjboyd]

In terms of setting prioritization we would take the VS Code setting over the debugpy setting or the other way around? I feel like the first one but wondering how we can note if a user configures debugpy.debugJustMyCode to respect it if they do edit that (which I assume is user-configurable somewhere)

[tboddyspargo]

In terms of setting prioritization we would take the VS Code setting over the debugpy setting or the other way around?

From the VSCode extension's perspective, I think we just need workspace config to override user confit and launch config to override global config. Does that sound reasonable?

I'm probably pretty uninformed about the patterns of usage with debugpy and how VSCode integrates with it, but here's my assumption: In terms of debugpy's in-code configuration capabilities (outside of VSCode), perhaps that will always take precedence over any of the VSCode settings? I'm not sure, but my intuition says that most of the VSCode settings will end up behaving as though the setting was passed via the CLI (which I'm guessing won't be in contention with anything else) and any direct debugpy.configure calls within code will obey whatever its internal configuration precedence logic is has against the CLI arguments. Therefore, I'd think that it would be sufficient to document the precedence of the VSCode extensions' configuration locations (workspace beats user, launch beats global) and indicate that it informs the CLI args that will be used to attach to the process.