-
-
Notifications
You must be signed in to change notification settings - Fork 642
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
Sandbox must be disabled for VS Code remote debugging to work #17540
Labels
Comments
Ahh I thought I remembered this working. This "works" for the The important thing is:
In Now to figure out how to adjust the mapping 😅 |
thejcannon
added a commit
to thejcannon/pants
that referenced
this issue
Nov 18, 2022
…unning in a sandbox (pantsbuild#17566) Fixes pantsbuild#17540 The key is that the DAP client is sending `pathMappings`, which normally sets `remoteRoot` to `"."` which for `run` isn't true. There's no easy way to have the server set it's own mapping so we monkeypatch.
thejcannon
added a commit
to thejcannon/pants
that referenced
this issue
Nov 18, 2022
…unning in a sandbox (pantsbuild#17566) Fixes pantsbuild#17540 The key is that the DAP client is sending `pathMappings`, which normally sets `remoteRoot` to `"."` which for `run` isn't true. There's no easy way to have the server set it's own mapping so we monkeypatch.
thejcannon
added a commit
to thejcannon/pants
that referenced
this issue
Nov 18, 2022
…unning in a sandbox (pantsbuild#17566) Fixes pantsbuild#17540 The key is that the DAP client is sending `pathMappings`, which normally sets `remoteRoot` to `"."` which for `run` isn't true. There's no easy way to have the server set it's own mapping so we monkeypatch.
thejcannon
added a commit
that referenced
this issue
Dec 8, 2022
Fixes #17672 and fixes #17692 Added new test-code which tests the `DebugAdapterRequest` by running it without `--wait-for-client`. This wouldn't catch issues like #17540 which require a client, but would catches issues like #17672 and #17692. Fixes: - Bad debugpy ICs - Untracked issue where the process would always return 0 - The config wouldn't be used if provided - Removes the reliance on `importlib_metadata` to load the entrypoint, instead re-enters the already executing pex in-process
thejcannon
added a commit
to thejcannon/pants
that referenced
this issue
Dec 9, 2022
Fixes pantsbuild#17672 and fixes pantsbuild#17692 Added new test-code which tests the `DebugAdapterRequest` by running it without `--wait-for-client`. This wouldn't catch issues like pantsbuild#17540 which require a client, but would catches issues like pantsbuild#17672 and pantsbuild#17692. Fixes: - Bad debugpy ICs - Untracked issue where the process would always return 0 - The config wouldn't be used if provided - Removes the reliance on `importlib_metadata` to load the entrypoint, instead re-enters the already executing pex in-process
thejcannon
added a commit
that referenced
this issue
Dec 10, 2022
…17768) Fixes #17672 and fixes #17692 Added new test-code which tests the `DebugAdapterRequest` by running it without `--wait-for-client`. This wouldn't catch issues like #17540 which require a client, but would catches issues like #17672 and #17692. Fixes: - Bad debugpy ICs - Untracked issue where the process would always return 0 - The config wouldn't be used if provided - Removes the reliance on `importlib_metadata` to load the entrypoint, instead re-enters the already executing pex in-process
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
Filed by request from @thejcannon
When running
./pants run --debug-apapter {path_to_target}
and using Visual Studio Code'sPython: Remote Attach
feature, VS Code is able to attach to the remote debug server but breakpoints are never hit when Pants sandboxes are used. Breakpoints only work when the Pants sandbox is explicitly disabled.Pants version
2.14.0
OS
macOS (haven't tested on Linux)
Additional info
The text was updated successfully, but these errors were encountered: