Smart Knit does not respect .RProfile / {renv}

[beansrowning]

Describe the bug Smart/background knitting session ignores workspace .RProfile. This is an issue in my case, as I use {renv} and the background process can't locate the library path even when the working directory is changed to "workspace root".

To Reproduce Steps to reproduce the behavior:

1. Pull up any rmarkdown template
2. use {renv} to install dependencies
3. Run "Knit"
4. See error

Do you want to fix by self? (We hope your help!)

I can assist, but don't code in TS normally.

Expected behavior Smart knit either launches non-vanilla by default, or has an additional option to respect workspace environment.

Screenshots If applicable, add screenshots to help explain your problem.

Environment (please complete the following information):

• OS: Win 10
• VSCode Version: 1.61.0-insider
• R Version: 4.1.0
• vscode-R version: 2.3.0

[ElianHugh]

Thanks for reporting this! I'll have to double check, but I suspect this is because the cwd isn't set when launching the knit process, should have a fix tonight

[ElianHugh]

@beansrowning would you be able to test if this PR solves the renv issue?

[beansrowning]

Yes, I'll try it out today @ElianHugh. Thanks for the quick work on that!

[beansrowning]

Ha, well now I've bricked my install. I uninstalled the extension, rebuilt your branch and installed that, and now none the the commands work:

I tried to revert by deleting the extension and re-installing 2.3 from VSCode, but it's still broken. Seems like this is a known bug, but is there any guidance?

#106, #6, #72

[ElianHugh]

Argh! It's weird that reinstalling didn't work, it makes me think that it didn't clear out the previous install.

Would you be able to delete any R extension folder that is present under '%USERPROFILE%.vscode\extensions'? It should be something like 'Ikuyadeu.r-2.3'.

Sorry for the trouble!

[beansrowning]

Ah, wiping the directory did the trick--thanks!

Unfortunately, I still can't get the vsix file I built to install correctly (or it appears to, and then results in the command not found errors above).

[ManuelHentschel]

Unfortunately, I still can't get the vsix file I built to install correctly [...]

Have you tried with the vsix file from here?

[beansrowning]

Unfortunately, I still can't get the vsix file I built to install correctly [...]

Have you tried with the vsix file from here?

That one did the trick, thanks! Fix confirmed working on my platform 🎉

[renkun-ken]

I update #807 so that the knit process is started from the knit working directory, i.e. either workspace root or document folder so that multi-root workspace is properly supported. I wonder what should be the behavior for the following scenario:

Workspace root contains .Rprofile and renv folder, and the rmd file is located in a subfolder (e.g. doc). If "document folder" is chosen as the knit working directory, should we also respect the .Rprofile and renv setup in the workspace root?

Or should we always start the knit process from the workspace root of the document since renv and .Rprofile is mostly setup in the workspace root?

[renkun-ken]

I tried the same in RStudio and its behavior is keeping the working directory of the knit process consistent with the knit working directory, i.e. if "document folder" is chosen, then the knit process is also started from the document folder, as currently implemented in #807.

[arnold-c]

I think I might be running into the same issue with {renv}, and believe that it may have to do with the knit wd implemented in #807. Similarly, VSCode-R cannot find the {renv} library using .libPaths() using the radian terminal when trying to knit (smart or otherwise), and therefore cannot knit files that contain packages in the {renv} library. The Rmd file is in a subdirectory or the workspace root which contains the renv/ folder and .Rprofile e.g., project-root/analysis/glm/test.Rmd. I believe that although RStudio keeps the wd of the knit process consistent with the output directory, it still finds the {renv} library, so I wonder if there's something else going on in RStudio? The code works with inline evaluation perfectly (i.e., when not knitting).

Another data point is that I am using a {targets} pipeline, and this runs perfectly in VSCode-R, as I believe this sets the wd to the project root during the pipeline run (ropensci/targets#230).

Thanks for the work putting this together - it's been great moving towards using VSCode for R!

OS: macOS Big Sur v11.6 VSCode Version: 1.62.0-insider R Version: 4.1.1 vscode-R version: 2.3.1

[altairwei]

Workspace root contains .Rprofile and renv folder, and the rmd file is located in a subfolder (e.g. doc). If "document folder" is chosen as the knit working directory, should we also respect the .Rprofile and renv setup in the workspace root?

I prefer this solution: .Rprofile and renv setup in the workspace root should be respected, even if "document folder" is chosen as the knit working directory.

When I write an Rmd document, I usually assume that the document's working directory (using a relative path to load the workspace's dataset) is where the document is located, and assume that the R environment is set up from the root directory.

[tarensanders]

@arnold-c have you found a workaround for this? I have the same issue - a project setup with {targets}, packages manged by {rend}, and an RMD in a subfolder of the workspace (/doc). Knitting as part of targets::tar_make() is fine, but if I want to just quickly render the RMD it cannot find packages unless I also install them in my main library. Did you find a way around this?

[arnold-c]

@tarensanders no, I'm afraid not really for the smart knit etc. I've found that updating to the latest {renv} GitHub/developer build has helped a lot with packages being located etc, and I just use rmarkdown::render(here::here("dir", "file")) in the command line if I want to knit outside of the {targets} pipeline. This obviously requires listing packages in the .Rmd file, but to point the file to _targets/ requires using the below chunk (see https://github.com/ropensci/targets/issues/230).

withr:with_dir(
    here::here(), {
    tar_load(target)
    }
)

[ElianHugh]

Thanks for the updates re: renv. I'll try to have a look at this over the coming days

[ElianHugh]

Hi @arnold-c and @tarensanders, sorry to bug both of you! As I haven't used renv before, I was wondering if I could get some more information on how your folders are structured (particularly where the .Rprofiles are located).

If I want to just quickly render the RMD it cannot find packages unless I also install them in my main library.

Does this mean that the renv/library folder has the appropriates packages for knitting, but it isn't being taken into account when smart knitting? If so, I think the expected behaviour would be that prioritise .Rprofile in workspace root. Would this appropriately fix the issue?

[tarensanders]

Happy to help if I can, @ElianHugh.

As I haven't used renv before, I was wondering if I could get some more information on how your folders are structured (particularly where the .Rprofiles are located).

A sample folder structure with renv (and targets) would look like:

• R/
  • some_funcs.R
• _targets/
• docs/
  • report.Rmd
• renv/
  • library/
  • activate.R
• .Rprofile
• renv.lock

This .Rprofile contains source("renv/activate.R") and then renv.activate.R contains code to change which library is being used (you probably already know this).

Does this mean that the renv/library folder has the appropriates packages for knitting, but it isn't being taken into account when smart knitting?

That's correct.

If so, I think the expected behaviour would be that prioritise .Rprofile in workspace root. Would this appropriately fix the issue?

I think that would solve the issue.

[ElianHugh]

Happy to help if I can, @ElianHugh.

If so, I think the expected behaviour would be that prioritise .Rprofile in workspace root. Would this appropriately fix the issue?

I think that would solve the issue.

~~Great, thank you for your help! I think what is happening is that the knit wd setting is overwriting any changes to the wd that may occur from the renv .Rprofile.~~

~~I wonder if it would make sense to have a third working directory setting that is something like "unchanged" or "defer to .Rprofile"~~

[ElianHugh]

OK, so a very basic change appears to fix renv with regard to knitting:

local_rprof <- ".Rprofile" %in% list.files()

# set the knitr chunk eval directory
# mainly affects source calls
if (nzchar(knit_dir) && !local_rprof) {
    knitr::opts_knit[["set"]](root.dir = knit_dir)
}

Not sure about checks/limitations on this however. E.g., perhaps only take into account a local .Rprofile if there is a renv folder

[renkun-ken]

What if we always start the knit process from workspace root and call setwd() afterwards before knitting to the user chosen knit directory?

[ElianHugh]

I see what you mean, although the actual wd isn't altered, just the knitr option.

[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.