Prevent .libPaths() in R from resolving symlinks-CodePudding

I have two almost identical systems. I install software in system1 (a remote testing environment) in /export/apps/ and then rsync the files to system2 in its /export/apps. For file system reasons, /export/ is really a symlink on each system. This usually works b/c for most many programs, any hard-baked paths contain the symlink and the file structure under the symlink is identical. So

system1 : /export/ -> /gpfs0/remote-test/export

system2 : /export/ -> /gpfs0/export

However, when I set .libPaths in R, R 'helpfully' resolves the symlinks. I have a strong suspicion that when I rsync this to system2, those resolved symlinks are going to break the installed software. E.g. (in R/4.0.0)

> .libPaths = .libPaths("/export/apps/opt/monocle3/1.0.0/")
> .libPaths()
[1] "/gpfs0/remote-test/export/apps/opt/monocle3/1.0.0"
[2] "/gpfs0/export/apps/easybuild/software/R/4.0.0-foss-2020a/lib64/R/library"

QUESTION :

Is there a way to prevent .libPaths() from resolving the symbolic link /export/ to its full path?

CodePudding user response：

Can you rsync the folder with your packages over and then specify their new location with .libPaths()?

CodePudding user response：

The .libPaths() function is pretty simple:

> .libPaths
function (new, include.site = TRUE) 
{
    if (!missing(new)) {
        new <- Sys.glob(path.expand(new))
        paths <- c(new, if (include.site) .Library.site, .Library)
        paths <- paths[dir.exists(paths)]
        .lib.loc <<- unique(normalizePath(paths, "/"))
    }
    else .lib.loc
}

Where your symlinks are being resolved is in the call to normalizePath(paths) near the end. So the answer to your question is "no, you can't tell .libPaths() not to resolve the symlink".

I suppose you could write your own version that didn't call normalizePath(), but that seems very risky: R is likely assuming that it has happened.

I would also assume that using rsync to move installed packages from one location to another is likely to break something in packages that have complicated configurations. Packages with StagedInstall: FALSE are allowed to assume this will never happen.

I think you're just going to have to install the packages again on system2 to make sure they are configured properly for that system.