Repository navigation
Proposal: Report relative paths to VS Code to support remote debugging #463
Description
Your proposal
rdbg reports absolute file paths to files on disk to VS Code. If rdbg had an option to report file paths relative to a specific root directory, then it could support remote debugging in VS Code across multiple machines.
Additional context
In our remote debugging setup, VS Code runs on one machine, but the process being debugged is on a second machine. Both computers have the same source tree, but at different absolute file paths.
Activity
ko1 commentedon Dec 27, 2021
Sorry I couldn't understand your proposal.
Understood:
Couldn't understand:
jvilk-stripe commentedon Dec 27, 2021
Correct!
We are not using VS Code's remote login support. We need rdbg to report relative paths so that they resolve on the machine running VS Code.
I hope that makes things clearer!
jvilk-stripe commentedon Dec 27, 2021
I might be able to contribute this feature if you feel OK with it.
ko1 commentedon Dec 28, 2021
Sorry I couldn't understand yet.
Assume
(1) machine M1 has src tree.
(2) machine M2 also has src tree.
Q1. Where do you want to run the VSCode and rdbg?
Q2. Now VSCode integration using UNIX Domain socket and it can not connect to the different macine (ex: M1 -> M2). How to connect it?
jez commentedon Mar 1, 2022
👋 I work with jvilk at Stripe, so I can help answer some of these question for him:
VS Code is open on a laptop, editing local files on the laptop (in our case, running macOS). VS Code is not using built-in remote development support. The files being edited have paths like
/Users/jez/stripe/pay-server/...When edits happen to files open in VS Code, they get saved to the local (laptop) file system. A custom script running
watchmanandrsyncwill notice file changes and send the new files to a remote development machine (in our case, running Ubuntu). It will sync the files to a folder like/pay/src/pay-server/...Meanwhile,
rdbgwill be running the code on the remote development machine. The file contents will be the same as those on the laptop, but the files will have different absolute paths.The plan is to use TCP/IP to connect to it. The
rdbgprocess will bind to a port on the remote linux machine, and we will connect to it likejez-dev-machine.<stripe-intranet-domain>:$RUBY_DEBUG_PORT. It's secure because the<stripe-intranet-domain>is not available to the public internet—we have a custom proxy server that will allow connecting directly to the TCP port on the remote linux machine from the macOS laptop over TCP.Basically, to
rdbg's eyes, it looks the same as if it were bound tolocalhoston the linux remote development machine. The only problem is that it has to work with relative paths likelib/foo.rbwhen setting breakpoints, instead of absolute paths.Please let me know if that helps clear things up, or if it makes it more confusing.
ko1 commentedon Mar 20, 2022
Ok, I understand the situation.
There are several points the full-path is shown.
Do you want to solve case 1?
jez commentedon Mar 21, 2022
Yes I believe that the DAP event case is what we care about.
ko1 commentedon Mar 21, 2022
All right. It's clear. We can support by debug.gem or vscode-rdbg (maybe), let me take a time to consider about it.
jez commentedon Mar 21, 2022
Thanks! If there’s anything I can ever help answer, or you’d like us to test something out, please don’t hesitate to @mention me.
firien commentedon Apr 21, 2022
here is the (start of) vscode-rdbg solution: ruby/vscode-rdbg#42
mbsmartee commentedon Jun 10, 2022
+1 This is important for teams using VSCode and Docker setups too.
booleanbetrayal commentedon Jun 22, 2022
We are running into the inability to use the official debugger running in Docker in tandem with VSCode due to this path resolution issue. We're currently tracking @firien 's implementation but would not be opposed to an upstream fix in the Gem if possible, either. =]
local_fs_map for DAP
local_fs_map for DAP
local_fs_map for DAP