how to ensure R run in subdirectories uses packrat library

[Matthew Stephens]

I have a packrat project where I have multiple subdirectories with code to be run.

Each subdirectory contains a Makefile with R CMD BATCH or RSscript commands to run code in that subdirectory (or subdiretories of that subdirectory).

I want these R CMD BATCH runs to use the packrat library - that, is I essentially want all subdiretories of my project to use the packrat library. 

What is the recommended way

to ensure that behavior? 

thanks!
Matthew

[Kevin Ushey]

Hi Matthew,

We currently don't have a well-paved road for accomplishing this, but here are some ideas...

You could handle this by explicitly calling `packrat::on()` yourself, e.g. from each sub-directory:

    packrat::on("../")

We could also update the implementation of `packrat::on()` so that, when called from a sub-directory, it automatically crawls upwards looking for the packrat folder, e.g.

    packrat::on() ## looks for directory (current or parent) containing 'packrat/packrat.lock' file

You could also add `.Rprofile`s to each subdirectory, with something like:

    owd <- setwd("../")

    source("packrat/init.R")

    setwd(owd)

It's also possible that we could control this with an environment variable, e.g. R_PACKRAT_PROJECT_ROOT, which could be easily set from a Makefile or other context. We don't do this currently but it doesn't seem like a bad idea...

Let me know if this steers you in the right direction, or if you have any thoughts on what you think would be the best solution here.

Kevin

--
You received this message because you are subscribed to the Google Groups "packrat-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to packrat-discu...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Matthew Stephens]

thanks!
We are currently experimenting with lines like
export R_LIBS_USER=../packrat/lib/*/*
in the Makefile.
This seems to be a satisfactory workaround for now.

Matthew

[Peter Carr]

Are there any new developments on this? I have a related but not identical use-case and want to know if PackRat will help. We deploy software to be run on HPC sites, where each command is run in a new working directory. E.g.

    ./jobs/id01

    ./jobs/id02

    et cetera

Is it possible to use PackRat in this scenario?

[Kevin Ushey]

Hi Peter,

The simplest way would be to populate each newly created working directory with a `.Rprofile` that calls the R commands you need, and / or a `.Renviron` that sets the environment variables needed. These files will automatically be read and executed by R on startup, and within there you can make the calls to e.g. `packrat::on()` as necessary.

Let me know if this steers you in the right direction,

Kevin

--

You received this message because you are subscribed to the Google Groups "packrat-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to packrat-discuss+unsubscribe@googlegroups.com.

[Peter Carr]

My high level goal is to update my system (see http://genepattern.org/) so that a new tool can be developed locally (perhaps in RStudio) and exported to run on the compute cluster as a GenePattern job.

I prefer to handle this with R environment variables. So the .Renviron seems promising. I haven't used PackRat, yet. Will you give me a few hints about how to implement this type of scenario? I need to support many different software modules which may have conflicting R package requirements. I run many jobs on the cluster and want to avoid re-installing all package dependencies for each run.

What .Renviron flags would I set to achieve this?

Thanks,
Peter

-- 
Peter Carr <pc...@broadinstitute.org>
Sr. Software Engineer
Broad Institute - GenePattern Team (http://genepattern.org/)