Tools: Isolate R library paths to those in container

[drpatelh]

Much like we have already done for Python it would be great if any processes that require R only look within the container for the associated packages. There have been a number of issues reported where users have reported R library/package conflicts when running nf-core pipelines. Most of the time this has been resolved by just renaming/deleting ~/.Rprofile and then re-running. However, this isnt a robust solution.

An alternative as tested by @mashehu would be to add an empty R_PROFILE_USER to nextflow.config in the env scope:

// Export these variables to prevent local Python/R libraries from conflicting with those in the container
env {
  PYTHONNOUSERSITE = 1
  R_PROFILE_USER=""
}

Strictly speaking this variable has to point to a file but that will be quite difficult given the way in which we automate our Docker builds. Unless we add in a separate line to touch an empty file in the container but then this may cause issues with -profile conda. If left empty like this then @mashehu suggested that a warning is generated during the pipeline execution. Please fill in the blanks and add more info here @mashehu.

See R docs

[mashehu]

Not much to add. The exact warning is:

WARN: Environment variable `R_PROFILE_USER` evaluates to an empty value

and seems to be printed every time an R script is invoked, so it can occur multiple times.
Another solution would be to add --vanilla to every Rscript command, as described here for snakemake: https://bitbucket.org/snakemake/snakemake/issues/970/ignore-r-profile-when-executing-r-scripts

[ewels]

https://rdrr.io/r/base/Startup.html

Then, unless --no-init-file was given, R searches for a user profile, a file of R code. The path of this file can be specified by the R_PROFILE_USER environment variable (and tilde expansion will be performed). If this is unset, a file called .Rprofile is searched for in the current directory or in the user's home directory (in that order). The user profile file is sourced into the workspace.

I wonder if we can just make an empty .Rprofile file in the work directory for processes involving Rscripts? Also a little hacky, but might avoid the warnings..

[drpatelh]

Or we just have an extra line in Dockerfile:

RUN touch .Rprofile

and the following in nextflow.config:

// Export these variables to prevent local Python/R libraries from conflicting with those in the container
env {
  PYTHONNOUSERSITE = 1
  R_PROFILE_USER=~/.Rprofile
}

~ should resolve to the top-level directory of the container no?

Will need to be tested to see if that gets rid of the warnings @mashehu reported.

"Most" people will be using containers anyway so we could just take the hit with conda.

[drpatelh]

Having 👀 the docs again. It appears we would have to do the same for .Renviron so the implementation should actually look like:

Dockerfile

RUN touch .Rprofile
RUN touch .Renviron

nextflow.config

// Export these variables to prevent local Python/R libraries from conflicting with those in the container
env {
  PYTHONNOUSERSITE = 1
  R_PROFILE_USER= "~/.Rprofile"
  R_ENVIRON_USER = "~/.Renviron"
}

I have now added this to the atacseq and chipseq pipelines to test.

[apeltzer]

Did that help @drpatelh ? :-)

[drpatelh]

Yep :+1: This solution works with Conda, Docker and Singularity. For Conda where these files won't be present in the environment the worst case scenario is that the user can touch local versions of these files and provide that via a custom config. May have similar issues with Biocontainers but I think the files not being present is tolerated by R.