CODEWITHSUNDEEP
rsymlink
irritable_phd_syndrome
irritable_phd_syndrome

Reputation: 5087

Prevent .libPaths() in R from resolving symlinks

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?

Upvotes: 1

Views: 205

Answers (2)

user2554330
user2554330

Reputation: 44997

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
}

Your symbolic links are being resolved 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.

Upvotes: 2

irritable_phd_syndrome
irritable_phd_syndrome

Reputation: 5087

I went ahead and installed the R package on our remote testing environment (system1) at /gpfs0/remote-test/export/apps/opt/monocle3/1.0.0. It works (at least I can load the library) on system1.

I then rsync'd it the installed packages to /gpfs0/export/apps/opt/monocle3/1.0.0 on system2 and it works there as well.

I did do some checking (i.e. find . -name "*.so" -print | xargs -I var grep -in remote-test var) of the shared libraries and the string remote-test was hard-baked into three of the shared libraries.

It appears that I got away with this this time (See user2554330's answer for why it may not work in the future). I was not hurt by any hard-baked paths as far as I can tell. In this instance, I could can move R libraries around without breaking things.

Upvotes: 0

Related Questions