Implement justMyCode fine grained control feature in debugger

[DonJayamanne]

This setting could expand into:

• MyCode - Just my code on/off (everything inside workspace directory is considered just my code, excluding virtual envs)
• Pkg - Enable debugging of site packages (Just my code is off)
• StdLib - Enable debugging of stdlibs (Just my code is off)

I.e. we have three states:

• MyCode
• Pkg
• StdLib
• Pkg + StdLib

Possibly even allowing users to define other directories that fall into Pkg category. E.g. user is importing modules from some other directory.

I'll try to come up with an extensible structure for this and then we can discuss.

Todo:

• Review how other extensions do this today (configuration)
• Review how VS structures the config settings today

[brettcannon]

Providing a way to provides overrides might also be useful (but probably not worth worrying about until someone asks for it).

And doing this as a string for future flexibility makes sense for if/when we provide the flexibility of just stdlib or just 3rd-party.

[DonJayamanne]

I'm holding off for now, as just my code is a little flaky in PTVSD.
Even if its fixed, we can introduce this in a later release, as Just My Code is an enhancement in VSC.

[qubitron]

I'd suggest that we consider "My Code" to be anything that is NOT inside of site_packages or in the stdlib.

I may open just one subdirectory in my code base but still reasonably expect to be able to step files in other parts of my code base. However, I wouldn't expect to step into site packages that I've installed, or the standard lib (since I can't easily modify those).

[brettcannon]

When you install something with pip install -e don't the files end up symlinked into site-packages? If so then this may still surprise people (but I also don't know if we can work around that).

[qubitron]

@brettcannon good point, I think it's fair to treat those as if they are external packages in that case

[DonJayamanne]

@brettcannon We might want to add this to the new milestone.

[qubitron]

@DonJayamanne I believe this needs upstream work from ptvsd

[DonJayamanne]

Blocked by microsoft/ptvsd#802

[qubitron]

Capturing discussion with Don, for now this setting will be justMyCode: true|false. True will define everything that is NOT in site packages as My Code. False will not apply any filtering.

Later if we want to add customizations we can add additional settings. The below are not in scope for this issue, but documenting them for future reference:

• justMyCode.excludeModules: list of modules to exclude from my code
• justMyCode.excludePaths: list of paths to exclude from my code (defaults to a $sitepackages variable, which would need to be added)
• justMyCode.includeModules: list of modules to include as my code
• justMyCode.includePaths: list of folders to include as my code

Filters would start by first excluding and then including. This allows users to debug into e.g. django.models by adding a single setting:
justMyCode.includeModules: ['django.models']

The reason to add these as separate settings is it allows you to turn the whole thing on/off without changing your workspace's definition of My Code.

[Almenon]

Will there be a option to skip stdlib but step into everything else? I rarely ever want to step into the standard python library but I step into pip modules sometimes.

[brettcannon]

@Almenon we haven't decided yet.

[Flamefire]

However, I wouldn't expect to step into site packages that I've installed, or the standard lib (since I can't easily modify those).

I do have exactly this use case: I'm debugging a failing python test that uses an installed package. The failure occurs in the installed package but is caused by my package. In order to understand what I did wrong I need to step into the installed package.

[qubitron]

@Flamefire to step into site packages you can disable the "justMyCode" feature. Does that work for you, or do you need to have separate control of skipping stdlib vs. site packages?

Right now we only have a single on or off switch for the feature, so we've decided for now that "my code" is anything that is NOT in site packages or the Python standard library.

Stepping into excessive library code/helper functions can really make debugging cumbersome when you are just trying to step through your own code so we're trying to avoid that.

[Flamefire]

How to disable that? I found debugStdLib and that does what you describe. I do not need separate control over stdlib vs site packages, all I need is to debug into those when required. Best would be to switch this in a running debugger, e.g. when debugging a single test case of pytest (run via the code lense)

[qubitron]

Yes, the debugStdLib does what you describe in the current release. Also in the current release "My Code" is defined as everything that's in the opened workspace in VS Code and excludes everything else (opt-in approach).

We're changing that in the next release to:

1. Rename the option to "justMyCode", debugStdLib will still work for backwards compatibility
2. Change the definition of "my code" from opt-in to opt-out: anything that's not in site packages or stdlib you can step through by default.

Being able to change it in the middle of a debug session is a good suggestion, we'll keep that in mind as we make future updates to this feature.

[Flamefire]

Being able to change it in the middle of a debug session is a good suggestion, we'll keep that in mind as we make future updates to this feature.

Is there actually an option to enable "justMyCode" for debug sessions started via the codelense?

[brettcannon]

@Flamefire no, for that you want microsoft/vscode-python#332

[dlitster]

@DonJayamanne I came here via #2888 after spending some time perplexed assuming the vs.code python debugger was broken or I hadn't told it properly where the standard python libraries were.
When this is enabled and you "step into" a system module, the call stack window just unhelpfully says "Template" above the main script you are running (in this case, ansible-inventory). It should give some indicator instead, like "justMyCode: true" that indicates "symbols for system libraries are hidden, set justMyCode: false in your launch config to display them".
Should I file a new ticket for this?

[brettcannon]

@dlitster yes, that's a separate issue.

[kevinushey]

I don't know if this is the most appropriate place for this to be filed, but it's pretty confusing to me that:

1. Visual Studio Code lets you set a breakpoint in 3rd-party Python code,
2. All of the UI within Visual Studio Code seems to indicate that the breakpoint is active, but
3. That breakpoint is ignored unless "justMyCode": false is set.

Would it be possible for this to be a bit smarter, and infer that if the user has set breakpoints within a 3rd-party module, then the user likely wants that breakpoint to work?

[brettcannon]

@kevinushey please open a separate feature request as this issue is specifically about providing varying levels of "openness" to justMyCode, not justMyCode in general.

[zhengpingzhou]

I don't know if this is the most appropriate place for this to be filed, but it's pretty confusing to me that:

1. Visual Studio Code lets you set a breakpoint in 3rd-party Python code,
2. All of the UI within Visual Studio Code seems to indicate that the breakpoint is active, but
3. That breakpoint is ignored unless "justMyCode": false is set.

Would it be possible for this to be a bit smarter, and infer that if the user has set breakpoints within a 3rd-party module, then the user likely wants that breakpoint to work?

Thank you so much, this works. And to be more specific, the "justMyCode": false option should be added to launcher.json in debugger configuration, not in settings.json (credit to this stackoverflow thread).

[brechtm]

I'm not sure why you would want to limit where breakpoints can be placed. Does this help improve performance when debugging?

Anyway, for anyone who wants to place breakpoints in third-party code while running tests, the following launch.json will enable that (found in microsoft/vscode-python#332, where I can't add any comments):

{
  // Use IntelliSense to learn about possible attributes.
  // Hover to view descriptions of existing attributes.
  // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Python: Current File",
      "type": "python",
      "request": "launch",
      "program": "${file}",
      "console": "integratedTerminal",
    },
    {
      "name": "Python: Unit Tests",
      "type": "python",
      "request": "test",
      "justMyCode": false,
    }
  ]
}

This is documented here: https://code.visualstudio.com/docs/python/testing#_debug-tests

I first tried setting the debug.allowBreakpointsEverywhere and python.dataScience.debugJustMyCode in settings.json to true and false respectively, but that didn't work.

[int19h]

Please don't use "debugStdLib" - it's a legacy, deprecated name for this property, and it'll be going away eventually. "justMyCode" is the one that will work going forward.

[brechtm]

Please don't use "debugStdLib" - it's a legacy, deprecated name for this property, and it'll be going away eventually. "justMyCode" is the one that will work going forward.

Thanks! I updated my comment to prevent confusion.

[johnnybigoode-zz]

Not sure if this is the same issue but my case 'justMyCode':false works if I'm using the system's python interpreter. If I switch to conda's it won't even go down standard library.

Is this expected? Is there anything else I should config?

[int19h]

@johnnybigoode It's a different issue - can you please file it separately, and describe it in more detail? Ideally, include the logs from "logToFile": true.

[fabioz]

Closing this issue.

I believe that what's asked here is already achievable through rules (if the standard justMyCode:false|true is not enough).

i.e.:

rules=[
   {"path": "**/other.py", "include":true},
   {"path": "**/another.py", "include":false},
]

Also, the debugger should notify whether breakpoints are actually active (meaning that if the breakpoint is excluded by some rule or justMyCode, there should be a visual indication now).

Feel free to reopen if you believe I'm missing something here.

[rrmistry]

@fabioz , how can we implement rules?

I can't seem to find this setting even in insider builds:

Can you reference the PR / extension-repo that allows this?

This is a long sought after feature.

---

What I am using as of this moment:

VS Code:

Version: 1.55.0-insider (system setup)
Commit: 04770364fdc1bebeca9d1a257df2cacce06b35d6
Date: 2021-03-05T15:40:03.281Z
Electron: 11.3.0
Chrome: 87.0.4280.141
Node.js: 12.18.3
V8: 8.7.220.31-electron.0
OS: Windows_NT x64 10.0.19042

Python Extension:

2021.2.625869727

[fabioz]

It's still not in the vscode-python schema, but it can already be used.

See: microsoft/vscode-python#13719 (comment)

[eddy-geek]

Full example of launch.json to display the full stack but starting in user code, ie without the useless stack of the runpy.py wrapper:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Python: Current File",
            "type": "python",
            "request": "launch",
            "program": "${file}",
            "console": "integratedTerminal",
            "justMyCode": false,
            "rules": [
                {"path": "**/runpy.py", "include": false},
            ],
            "env": {
                "PYTHONPATH": "${workspaceFolder}"
            },
        }
    ]
}