Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

Get another program to find packrat-managed library

17 views
Skip to first unread message

Jessica

unread,
Feb 26, 2020, 10:25:52 AM2/26/20
to packrat-discuss
I am brand-new to Packrat.  I needed a package manager because I am using a tool which requires an older version of an R package, and when I downgraded that package I messed up a bunch of dependencies.  After nuking and rebuilding my entire R library, I found out about Packrat and decided to use it for this project.  I created a local library that only contains the necessary R packages (which is just this one: a pre-1.16.0 version of pROC), and use it when I run this tool.

The problem is that I do not know how to point the tool towards my Packrat library.  I am running the tool from the same directory where the packrat library lives, but it gives me an error because it cannot find the package it needs.  (Error is "Exception: Please install the 'pROC' library for R first.").  The tool is ROCker and it is built on Ruby.  I can find the line of code that checks for the pROC library, but I don't speak ruby so I don't really understand what it's doing.  It looks like a bash call to maybe search for the package on my path?  

This is where the error points me: 
/home/.local/lib/ruby/gems/2.7.0/gems/bio-rocker-1.5.2/lib/rocker/step/compile.rb:31:in `compile!'

This is the code on line 31 of compile.rb: 
bash("echo \"library('pROC')\" | #{@o[:r]} --vanilla",
         "Please install the 'pROC' library for R first.")


The general question is this: how do I get ROCker (or any tool) to "see" where my special packrat library is and use it, given that I am already running the tool from the same directory where the packrat directory is found?

Thanks.  I appreciate the help.  Happy to post more info if needed.

Kevin Ushey

unread,
Feb 26, 2020, 12:25:50 PM2/26/20
to Jessica, packrat-discuss
If I understand correctly, the problem here is that Packrat relies on being able to set the library paths in a startup .Rprofile (at the root directory of your project) to function. However, this tool is trying to launch R with 'R --vanilla', which forces R to ignore any existing .Rprofile / .Renviron files. I'm not sure if that behavior can be configured in the tool or not, but I believe that's the underlying cause.

One way around this would be to force R to see the Packrat library path even in this case would be to set the R_LIBS environment variable, e.g.

R_LIBS=/path/to/packrat/library/tool

Best,
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/packrat-discuss/f924d47c-6ca5-499e-a4b7-45ddb2a45bc7%40googlegroups.com.

Jessica

unread,
Feb 27, 2020, 8:56:11 AM2/27/20
to packrat-discuss
Hi Kevin,
Thanks for your reply.

Your reply makes sense.  Truthfully, I didn't fully understand these consequences '--vanilla' option.  Removing the '--vanilla' option from the code that checks for existence of pROC didn't work - ROCker still can't find the pROC package.  Moving to your next suggestions, I've read up a bit this morning on setting R_LIBS.  Not quite sure how to proceed.

I learned this from cgillespie's Efficient R Programming: "It is important to know the location of the .Rprofile and .Renviron set-up files that are being used out of these three options. R only uses one .Rprofile and one .Renviron in any session: if you have a .Rprofile file in your current project, R will ignore .Rprofile in R_HOME and HOME. Likewise, .Rprofile in HOME overrides .Rprofile in R_HOME. The same applies to .Renviron: you should remember that adding project specific environment variables with .Renviron will de-activate other .Renviron files."

So I guess the problem is that ROCker is either a) ignoring all the .Rprofiles because of the --vanilla option (although removing that doesn't fix it), or b) only looking a specific place for the .Rprofile, or c) something else.  C Gillespie warns against changing the "main" .Rprofile(s) (i.e.the ones in R_HOME and HOME), but if ROCker can only see these then I guess I have to try that.  I'm just adding a lib path and I can always remove it.  However, all I have is the default R_HOME/etc/.Rprofile_site.  My R_PROFILE and R_PROFILE_USER environment variables are unset.  I don't know if I should set one of them to include R_LIBS=/path/to/packrat/library/tool.  If so, I will need to do some research to find an example of what else it should contain.  Do you think this is the right path forward?  I don't think I should change my default .Rprofile_site file.

Another thing I'm unclear on (regarding Packrat): no matter what my working directory is, .libPaths() always includes only the Packrat library.  I expected the value of .libPaths() to change based on my current working directory: when I'm inside my Packrat project location, I expect it to see the local project .Rprofile (and Packrat library location).  Outside of that, I expect it to default to the library location specified in .Rprofile_site.  See below (I added my comments with hashtags after pasting it below):

# Location of my project
> getwd()
[1] "/home/data/rocker"
> .libPaths()
[1] "/home/data/rocker/packrat/lib/x86_64-pc-linux-gnu/3.2.3"
[2] "/home/data/rocker/packrat/lib-ext/x86_64-pc-linux-gnu/3.2.3"
[3] "/home/data/rocker/packrat/lib-R/x86_64-pc-linux-gnu/3.2.3"
# Change location to project's parent directory
> setwd("/home/data")
> getwd()
[1] "/home/data"
# Library path location is still the same
> .libPaths()
[1] "/home/data/rocker/packrat/lib/x86_64-pc-linux-gnu/3.2.3"
[2] "/home/data/rocker/packrat/lib-ext/x86_64-pc-linux-gnu/3.2.3"
[3] "/home/data/rocker/packrat/lib-R/x86_64-pc-linux-gnu/3.2.3"
# Try setting it to a totally different directory
> setwd("/home/src/")
> getwd()
[1] "/home/src"
# Library location is still the same
> .libPaths()
[1] "/home/data/rocker/packrat/lib/x86_64-pc-linux-gnu/3.2.3"
[2] "/home/data/rocker/packrat/lib-ext/x86_64-pc-linux-gnu/3.2.3"
[3] "/home/data/rocker/packrat/lib-R/x86_64-pc-linux-gnu/3.2.3"

What don't I understand about how Packrat functions?  (This seems unrelated, but I suspect understanding Packrat better might help me troubleshoot my main problem).

Thank you again.




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

Kevin Ushey

unread,
Feb 27, 2020, 1:14:07 PM2/27/20
to Jessica, packrat-discuss
The main things to note:

1. Packrat writes a project-local .Rprofile for the project,
2. R sessions launched in that directory will execute the code in that .Rprofile,
3. This implies that R sessions launched in Packrat projects will automatically enter "Packrat mode".

Because Packrat writes a project-local .Rprofile, the .Rprofile in your home directory will be ignored. Code in your etc/Rprofile.site will be executed, but it is executed before the project .Rprofile so the library paths set in the project .Rprofile take precedence.

Note that changing the working directory in an already-started R session will not change the library paths; it all depends on (when using Packrat) the working directory that was set when the R session was launched.

R_PROFILE and R_PROFILE_USER are normally unset, you only need to set those if you want to force R to look in a specific location for R profiles. This normally is not required.




To unsubscribe from this group and stop receiving emails from it, send an email to packrat-discu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/packrat-discuss/6aca4b6a-8758-4659-98e6-f9aab35ed0f6%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages