Allow to launch the debugger with options for e.g. justMyCode

[echarles]

For jupyterlab/jupyterlab#11566, there is a need to launch the debugger with configuration options, like justMyCode documented on https://github.com/microsoft/debugpy/wiki/Debug-configuration-settings

I have done a quick scan on how to achieve this, but have not find a way.

Any pointer to implement this feature will be useful.

[vidartf]

Note that currently when I try to step into the statement "import tornado", I get the following WS messages (idle/busy removed for clarity):

• A debug_reply to the stepIn.
• A "continued" debug event.
• An "output" event with the following body.output: Frame skipped from debugging during step-in.\nNote: may have been skipped because of \"justMyCode\" option (default == true). Try setting \"justMyCode\": false in the debug configuration (e.g., launch.json).\n
• A "stopped" debug event.
• A "stackTrace" debug request.
• A debug reply to the stack trace with the following frames:

  0: {id: 5, name: "run_cell", line: 532, column: 1,…}
  1: {id: 6, name: "do_execute", line: 355, column: 1,…}
  2: {id: 7, name: "execute_request", line: 664, column: 1,…}
  3: {id: 8, name: "dispatch_shell", line: 369, column: 1,…}
  4: {id: 9, name: "process_one", line: 462, column: 1,…}
  5: {id: 10, name: "dispatch_queue", line: 473, column: 1,…}
  6: {id: 11, name: "start", line: 677, column: 1,…}
  7: {id: 12, name: "<module>", line: 16, column: 1,…}
  

Some comments: There is a console output related to "justMyCode". The debugger seems very confused about what it should debug and not. I.e. I am not able to step into the tornado code during its import, but I am stepping into the ipykernel internals..

[echarles]

I guess you have set Kernel.debug_just_my_code=False. It should be True by default, per https://github.com/ipython/ipykernel/pull/863/files#diff-874f94d86eaa767fb34865311dd8fd8c0d9a2fa6c49bc21f28690058f3dfa83cR133

If you set it to False, indeed step by step debugging may drive you crazy going into the ipykernel source. When I have used it, I have use the kernel source panel, opened the files I wanted to look at, set some breakpoints there, and let the debugger go from breakpoint to breakpoint.

[echarles]

To be sure if it is relate to that new setting, you could try to downgrade ipykernel and see if the behavior is reproduced.

[vidartf]

I guess you have set Kernel.debug_just_my_code=False

I haven't touched that setting, and I confirmed that none of my config files sets this value.

[echarles]

Which version are you using? Can you try with 6.9.0 and see if you face the same?

[vidartf]

I was on master (actually PR branch #875) trying to debug something else. I'll test 6.9.0, and also see if I can capture this behavior in a unit test.

[vidartf]

@echarles I think the issue was that I didn't have debug_just_my_code set to true, and it then "steps off the edge of the cell", i.e. the debugger continues allowing you to step through instructions after the cell has finished executing.

[echarles]

debug_just_my_code trait is defined as True by default. Do you get it False if you don't set it via config?

[vidartf]

When testing with ipykernel 6.9.0:

• It does not step into library import statements.
• It does not step into library methods.
• If you click "stepIn" on the last line of execution in a cell (and that e.g. is a simple print statement), it completes execution of the cell, but will break again immediately when the next cell is executed.

When testing on #875 (with no config of debug_just_my_code done):

• It does not step into library import statements.
• It does not step into library methods.
• If you click "stepIn" on the last line of execution in a cell (and that e.g. is a simple print statement), it steps into the code of the kernel. For me, with a print statement it steps into "[...]\ipykernel\iostream.py" for handling stream output.

[antoniivanov]

Is it possible in Jupyterlab to set debug_just_my_code to false somehow so I can debug code inside a library.

If no would that be addressed?