posit-dev / posit-dev/positron
debug doesn't open source file when used on renv installed packages
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 4.3k
- Forks
- 184
- Avg merge
- 1d 9h
- Merged PRs (30d)
- 195
Description
System details:
Positron and OS details:
Positron Version: 2025.09.0 build 139
Code - OSS Version: 1.103.0
Commit: 30e3d0a74e09a0f6640929822cb57a326671360e
Date: 2025-08-29T18:34:16.368Z
Electron: 37.2.3
Chromium: 138.0.7204.100
Node.js: 22.17.0
V8: 13.8.500258-electron.0
OS: Linux x64 6.12.10-76061203-generic
Session details:
R 4.4.1
Describe the issue:
When debuging a function, I get a file opened, with the debugger enabled, on functions installed in the base system library. When I try the same thing on a function from a library managed by renv, the file "can't be opened".
I've tried updating to the latest version of renv, and re-installing the dplyr package (rebuild = TRUE) in the example below, and I still get the error.
Steps to reproduce the issue:
- Use
renvto manage packages. - Install
dplyr. - Try to debug a
mutatecall.
Expected or desired behavior:
The file is opened, and debugger runs properly.
I am attaching two screencasts, one where I am performing the debug using a non-renv managed session, and one where I am.
Works:
https://github.com/user-attachments/assets/39774416-536b-49c7-89e3-8edbdfee08b0
Fails:
https://github.com/user-attachments/assets/d67111df-4ec2-4aa3-a150-5bcc0274557a
Were there any error messages in the UI, Output panel, or Developer Tools console?
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the issue with an renv-managed dplyr installation and compare it with debugging the same mutate call outside renv. Trace the source-file opening path for the debug session and use the reported UI error as the failure signal; done means the package source file opens and the debugger runs properly.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- r
- Domain
- developer-experience, tooling
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 68/100