Repository navigation
Resolve symlinks when running debugger in bazel sandbox #17002
Description
Discussed in #15897
Originally posted by koenlek April 8, 2021
I'm using bazel to build and run my python code. Bazel creates a 'runfiles' directory, which is used as a sandbox that contains all the runtime deps of my command. This runfiles directory is mainly made up by files that are symlinked into the directory.
When I run such code under the ptvsd debugger, it will open the file using the symlink path (i.e. the path in the runfiles directory), which is the same file as what I have in my git workspace. Luckily, it picks up my breakpoints as set on the original file properly, but it feels a bit messy, because:
- I often end up with two open copies per file: the one from my git workspace, and the one from the runfiles directory (which luckily is a symlink)
- Visually the UI doesn't sync both files well: break points set in either file will work, but will only show in one of both files...
Perhaps we could add a debug option: "dereference_symlinks"? If true, we make VSCode resolve the symlink to it's original path (readlink -f path/to/symlink)?
Note: my main use case is on Linux, but I think it should be straightforward to make this work on MacOS and Linux. For Windows I'm not so sure. I believe bazel has some experimental symlink runfiles support for Windows, so it might depend on that.
Activity
koenlek commentedon Aug 18, 2021
It looks like I've found a workaround for this. Just add the following to the debug config:
Although this seems like a no-op, it actually seems to effectively take care of symlink resolution for us.
brettcannon commentedon Sep 1, 2021
Thanks for the feature request! We are going to give the community 60 days from when this issue was created to provide 5 👍 upvotes on the opening comment to gauge general interest in this idea. If there's enough upvotes then we will consider this feature request in our future planning. If there's unfortunately not enough upvotes then we will close this issue.
brettcannon commentedon Nov 1, 2021
Thank you for submitting your feature request and everyone who considered it! Unfortunately this issue did not receive enough votes over the allotted time, and so we are closing the issue.