pantsbuild
pants run --debug-adapter and run in sandbox prevent vscode from stopping at breakpoints
Describe the bug
Using pants test --debug-adapter works great but with pants run --debug-adapter the breakpoints aren't hit.
The debugger stops for exceptions, just not breakpoints added in vsccode.
Setting default_run_goal_use_sandbox to false fixes it.
Pants version 2.16.0
OS Ubuntu
Additional info Using vscode 1.80.2, python 3.10, debugpy 1.6.7
Can you help with a reproduction repo?
Or tell us your settings? E.g. minimal pants.toml and BUILD file? Thanks!
Here you go - this seems to be enough to reproduce. Works with any *.py file
pants.toml
[GLOBAL]
pants_version = "2.16.0"
backend_packages = [
"pants.backend.python",
]
[source]
# The Python source root is the repo root.
root_patterns = ["/"]
[python]
# The default interpreter constraints for code in this repo.
interpreter_constraints = ["==3.10.*"]
BUILD
python_sources()
Hi! @thejcannon do you have any updates on this issue? We stumbled upon this problem as well.
As mentioned in the ticket description, the debugger stops for exceptions but we can see that the actual code running is from the sandboxed environment (which explains why vscode breakpoint are not triggered, I guess).
And the hack from the description does indeed work. That is, running PANTS_PYTHON_DEFAULT_RUN_GOAL_USE_SANDBOX=False pants run --debug-adapter file.py and then attaching the debugger via the following vscode launch config triggers the breakpoints:
{
// 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: Attach to process",
"type": "debugpy",
"request": "attach",
"connect": {
"host": "127.0.0.1",
"port": 5678
},
"pathMappings": [
{
"localRoot": "${workspaceFolder}",
"remoteRoot": "${workspaceFolder}"
}
]
}
]
}
No update. I've taken a step back from the project at the moment to allow myself to focus on my new job.
If you're feeling spicy enough to dive in, Id be happy to review a PR. But otherwise I'm not doing much active development.
I don't think I can face it at the moment but thanks for the quick reply. Congrats for the new job!
On Fri, Feb 9, 2024 at 4:53 PM Josh Cannon @.***> wrote:
No update. I've taken a step back from the project at the moment to allow myself to focus on my new job.
If you're feeling spicy enough to dive in, Id be happy to review a PR. But otherwise I'm not doing much active development.
— Reply to this email directly, view it on GitHub https://github.com/pantsbuild/pants/issues/19613#issuecomment-1936171467, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEZ226O4YWRSVQLQM3EONWLYSZA6ZAVCNFSM6AAAAAA3SSJ2ISVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZWGE3TCNBWG4 . You are receiving this because you commented.Message ID: @.***>
Well, a colleague of mine found the issue!
Replacing the value of "remoteRoot" field with "." magically works (I guess, this is how vscode infers the location of the breakpoints 🪄). So no need for default_run_goal_use_sandbox and this issue can technically be closed, I gues.
{
// 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: Attach to process",
"type": "debugpy",
"request": "attach",
"connect": {
"host": "127.0.0.1",
"port": 5678
},
"pathMappings": [
{
"localRoot": "${workspaceFolder}",
"remoteRoot": "."
}
]
}
]
}
Oh, that reminds me of https://github.com/fabioz/PyDev.Debugger/pull/243 😭