Working directory inference from '.Rproj' files

[18kimn]

trafficstars

I apologize in advance if this issue has been asked/closed/addressed! I couldn't find it in the issues tab or the wiki.

Is your feature request related to a problem? Please describe. It's not a huge problem, but it would be nice to have an option making the generated R session (e.g. when a piece of R code is run through 'R: Run Comnand in Terminal') be created with the working directory set to the R project that the code was written in. This would match the paradigm of R projects and offer support similar to that of RStudio

For example, in a VSCode workspace resembling:

- top-level-folder
    - my-r-project  
        - my-r-project.Rproj
        - script-1.R
    - a-different-folder
        - script-2.R
        - a-different-project.Rproj

If code from script-1.R was run, it would be nice for it to be run relative to my-r-project, rather than top-level-folder (as is the current behavior).

Describe the solution you'd like

An option called r.workingdirectory, with possible values being

• workspace: uses the highest folder in the VSCode workspace that the code was run in, I believe this matches the default behavior
• Rproj: beginning from the directory of the file, looks for a .Rproj file; if it sees one, it uses that directory, if it doesn't, it looks one directory higher and repeats until either R_HOME or '/' is reached
• file: uses the directory that this file is contained in, without looking any higher

Describe alternatives you've considered

The alternative and current strategy is to simply run setwd() when the working directory does not match what is desired, which is still not that bad.

Edit: I've found another alternative is to edit '~/.vscode-R/init.R', which could serve as a per-user workaround. I think a dedicated option would still be best, but yep!

[ElianHugh]

In the workspace example above, when you source script from both folders, is the expected behaviour any of the following?

• a new terminal is created for each .Rproj when sourcing
• wd is set in the same terminal every time a script is sourced from a new .Rproj

[18kimn]

Ah, good point, my view is that the first option would be best. E.g. there would be one session for my-r-project and a different one for a-different-project. Definitely open to suggestions.

That sounds like quite a bit more work/harder to implement, so a fallback could be just using the same terminal and same working directory when code from a different project is run. Changing the working directory could make things messy for users here (I think vscode-R should set it once before the session starts and not touch it afterwards)

[18kimn]

For users, something like the following could be put at the end of your ~/.Rprofile to make this happen:

if (interactive() && Sys.getenv("RSTUDIO") == "" ) {
   local({
      source(
        "~/.vscode/extensions/ikuyadeu.r-2.3.4/R/session/init.R",
        chdir = TRUE, local = TRUE
      )
      old_init_last <- init_last
      init_last <- function() {
        old_init_last()
        start <- rstudioapi::getActiveDocumentContext()$path

        current <- start
        rproj_found <- FALSE
        while (!rproj_found) {
          current <- dirname(current)
          files <- list.files(current, full.names = TRUE)
          rproj_found <- (length(grep("\\.Rproj", files)) > 0)
          # safety check; don't look past HOME or "/" and just use the original path instead
          if (current %in% c(Sys.getenv("HOME"), "/")) {
            current <- dirname(start)
            rproj_found <- TRUE
          }
        }
        setwd(current)
      }

      assign(".First.sys", init_last, envir = globalenv())
  })
}

The slightly obtuse syntax is because rstudioapi::getActiveDocumentContext() only works after the original init_last function from vscode-R finishes setting up the rstudioapi emulation.

[eitsupi]

Why not use the {here} package?

[18kimn]

I do use the here package a bunch (e.g. Rmd documents) but I think for package development and other settings it can be annoying/bad practice to add another dependency. Also, some vscode-R commands like r.build and r.test only work when the current working directory points to the package root, which here does not address. Using here more fundamentally means requiring user intervention for something vscode-R could just handle out of the box, as RStudio does, and thus address the issue at a larger scale

More generally, I think it'd be great if vscode-R implemented the Rproject system, most importantly filepaths support as described here but also

• some formatting options (#763)
• workspace caching and history through .Rproj.user
• more tooling for package development (UI for building/testing/documenting packages are inferred from *.Rproj options)
• whether to use pdfLaTeX/XeLaTeX for knitting files,

and so on. vscode-R doesn't have to implement all of these but I think it'd be better to implement Rproj features than for users to have to rely on packages like here. This support could begin with working directory inference

[ElianHugh]

This might also be useful re: extending support for .Rproj https://community.rstudio.com/t/documentation-about-rproj-files/29250/4

[github-actions[bot]]

This issue is stale because it has been open for 365 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 14 days since being marked as stale.

[dereckmezquita]

Are there any updates on this? I'm interested; I have the same problem as described by OP.

[github-actions[bot]]

This issue is stale because it has been open for 365 days with no activity.