Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Breakpoints in non-stdlib modules named io.py are always skipped #542

Open
ollie-bell opened this issue Dec 29, 2024 · 3 comments
Open

Breakpoints in non-stdlib modules named io.py are always skipped #542

ollie-bell opened this issue Dec 29, 2024 · 3 comments
Assignees
Labels
info-needed Issue requires more information from poster triage-needed Needs assignment to the proper sub-team

Comments

@ollie-bell
Copy link

ollie-bell commented Dec 29, 2024

Any breakpoint within a non-stdlib module named io.py will always be skipped.

e.g. consider the python package:

.
├── mypackage
│   ├── __init__.py
│   ├── io.py
│   └── main.py
└── pyproject.toml
# mypackage/io.py

def foo():
    return "hello from mypackage.io.foo"
# mypackage/main.py

from mypackage.io import foo


def main():
    return foo()


if __name__ == "__main__":
    main()

If you add a breakpoint inside mypackage.io.foo it will always be skipped, and you cannot step into that module.

Renaming the module to anything else fixes the issue.

PDB honour's breakpoints in that module (i.e. add breakpoint() in mypackage.io.foo and running python -m mypackage.main)

@github-actions github-actions bot added the triage-needed Needs assignment to the proper sub-team label Dec 29, 2024
@ollie-bell ollie-bell changed the title Breakpoints in local modules named io.py are always skipped Breakpoints in non-stdlib modules named io.py are always skipped Dec 29, 2024
@eleanorjboyd
Copy link
Member

How are you debugging? Are you using a config? Did you set the justMyCode to false?

@eleanorjboyd eleanorjboyd added the info-needed Issue requires more information from poster label Jan 7, 2025
@eleanorjboyd eleanorjboyd self-assigned this Jan 7, 2025
@ollie-bell
Copy link
Author

ollie-bell commented Jan 7, 2025

I have "debugpy.debugJustMyCode": false in my global vscode settings, other than that no special config, just the standard debug current file.

If I make a launch.json with "justMyCode": true then attempting to step into the call to foo() from mypackage.io gives the message:
Image

With "justMyCode": false, attempting to step in weirdly puts me into some random part of the stdlib (I had no breakpoint set here)
Image

... again, if change the name of mypackage.io module to anything else it works as expected.

The behaviour occurs regardless of whether mypackage is installed as editable or not.

Have tried launch config for both "Current File" and "Module", both behave the same:

{
    // 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 Debugger: Module",
            "type": "debugpy",
            "request": "launch",
            "module": "mypackage.main",
            "justMyCode": false
        },
        {
            "name": "Python Debugger: Current File",
            "type": "debugpy",
            "request": "launch",
            "program": "${file}",
            "console": "integratedTerminal",
            "justMyCode": false
        }
    ]
}

About Visual Studio Code:

Version: 1.96.2
Commit: fabdb6a30b49f79a7aba0f2ad9df9b399473380f
Date: 2024-12-19T10:22:47.216Z
Electron: 32.2.6
ElectronBuildId: 10629634
Chromium: 128.0.6613.186
Node.js: 20.18.1
V8: 12.8.374.38-electron.0
OS: Darwin arm64 24.1.0

@ollie-bell
Copy link
Author

FWIW I have just tested this on a different machine (still macOS arm64) with completely fresh installs of Python and vscode... and I continue to observe this behaviour.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
info-needed Issue requires more information from poster triage-needed Needs assignment to the proper sub-team
Projects
None yet
Development

No branches or pull requests

2 participants