I'm working on a Windows 10 machine and would like to use renv for a project which is located on a shared network drive.
I have taken the following steps before initializing renv:
In a project-level .Renviron, I set RENV_PATHS_ROOT to the shared network drive to store the cache on the same volume as the project (and further upcoming projects).
I used renv::settings$use.cache(TRUE) in case the cache is still disabled by default on Windows.
After initializing renv I found both a folder "cache" and a folder "renv/library" on the shared network drive, both containing copies of all packages used in my project from my user library. To me it seems that it was not possible to form junction points on the network drive, so that all packages were copied to the library instead (as outlined in the related topic linked above). Does this problem still exist and is the current recommendation to not use the cache when working on a network drive? Or is there any feasible workaround?
renv uses junction points on Windows, to create "links" from the project library to the cache when possible, and the project library is normally located within the project's renv/library folder. Unfortunately, this doesn't work across different drives -- in these cases, renv will copy (rather than link) from the global cache.
One way to fix this would be to use a custom library path for your project on the shared drive; e.g. in your .Renviron:
RENV_PATHS_LIBRARY = <path>
where <path> is some suitable path located on your shared network drive.
I put both the cache and the project library on the same shared network drive and - with these settings - got the packages copied twice (once into the project library and once into the cache).
Where do I put the cache in the solution you suggested? Also on the shared network drive (by setting both RENV_PATHS_LIBRARY and RENV_PATHS_ROOT to a path on the shared network drive)? Or do I use default settings for the cache, so that it is put on my local drive (by only setting RENV_PATHS_LIBRARY to a path on the shared network drive)?
Ultimately, the goal would be to ensure that the project library and the cache both live on the same drive. It's possible that junction points simply aren't supported on the networked filesystem, though (they're only available with NTFS file systems) so that could also explain the behavior you see.
Note that the cache path is controlled by RENV_PATHS_CACHE, but defaults to ${RENV_PATHS_ROOT}/cache.