Is there any documentation on manually installing a package in a user library when the R.home() path is locked down and incomplete (no etc, no bin, just library?) The system does NOT support shelling out to execute R CMD, which I believe standard R does.
I would like to build existing source packages (from CRAN) and install into a user library directory, so that I can use the library() function and get all the usual namespace and *.Rdx and *.Rdb files.
At the moment, I'm plodding through install.packages, tools::.build_package, and tools:::.install.packages source, using a standard MacOS R and the r source. Hopefully this has been documented in a more user-friendly fashion and my google searches have missed it.
Thanks.
You don't need to use a different install.packages method, rather you only need to specify a writable location for storing packages and give it precedence over the system default one. A simple way to accomplish this is to set an R_LIBS environment variable. For instance, in my .bashrc I have
export R_LIBS='/home/username/.local/lib/R-3.3.3'
Then, by default, all packages are installed here. Further, packages installed both here and the system-wide location will give priority to the ones here when loading.
You can verify that the location is being used by checking .libPaths() in your R session.
Related
I have some code in my R profile that I've found interferes with package installation. For example, I like to automatically load devtools when I'm working on packages, so I have this
if (file.exists("DESCRIPTION")) {
try({suppressMessages(library(devtools))})
}
However, I've found that this interferes with package installation, I get errors like ERROR: lazy loading failed for package ‘rlang’. If I comment out the loading of devtools in the R profile, the package installs without error.
Is there any way to check if .Rprofile is being executed during package installation so that I could put that condition in the if and stop devtools from loading at inappropriate times?
I’d generally recommend against putting such code into your ~/.Rprofile! — The ~/.Rprofile should contain only general configuration that is always valid. For further customisation, use a project-local ~/.Rprofile instead.
However, I would make one exception to the above guideline, because one useful distinction you can make is to only execute certain code in interactive sessions:
if (interactive()) {
if (file.exists("DESCRIPTION")) {
try({suppressMessages(library(devtools))})
}
}
.Rprofile files are sourced on R startup. They won't be called later by other functions so you can't use the checking logic during install.packages().
For this reason loading packages using RProfile is not always advisable as it can make your code non-reproducible. However, as a helper package, devtools is probably a good exception (ignoring your particular problem here).
If you use base R only you can tell R not to load Rprofile during startup by using the --vanilla or --no-init-file arguments.
If you are using RStudio one workaround would be to use project level Rprofile files. Rstudio starts a new R session for each project, and loads the user Rprofile from the project root. If it then can't find that it will attempt to load the user RProfile.
Create a new project and within the the project options tick the option to disable the Rprofile loading.
Whenever you want to install a package switch to this project.
One caveat is to make sure you are running this as the only project session open, having multiple RStudio sessions open when installing new packages can lead to problems without putting the Rprofile in the mix.
Rstudio article on startup files https://support.rstudio.com/hc/en-us/articles/360047157094-Managing-R-with-Rprofile-Renviron-Rprofile-site-Renviron-site-rsession-conf-and-repos-conf
Base R documentation on R initialization https://stat.ethz.ch/R-manual/R-devel/library/base/html/Startup.html
A diagram of the R startup flow and some commentary on use of renviron and rprofile
https://rstats.wtf/r-startup.html
I have read the R FAQS and other posts but I am a bit confused and would be grateful to know whether I did everything correctly.
In Windows, in order to modify the default library folder I created a file Renviron.site and put inside E:/Programs/R-3.3.0/etc.
The file has only one line saying
R_LIBS=E:/Rlibrary
When I open R and run .libPaths() I see E:/Rlibrary as [1] and the default R library E:/Programs/R-3.3.0/library as [2].
This should mean that from now on all packages I will install will go in E:/Rlibrary but at the same time I will be able to load and use both packages in this folder and those in the default location. Am I correct?
When you load a package via library, it will go through each directory in .libPaths() in turn to find the required package. If the package hasn't been found, you will get an error. This means you can have multiple versions of a package (in different directories), but the package that will be used is determined by the order of .libPaths().
Regarding how .libPaths() is constructed, from ?.R_LIBS
The library search path is initialized at startup from the
environment variable 'R_LIBS' (which should be a colon-separated
list of directories at which R library trees are rooted) followed
by those in environment variable 'R_LIBS_USER'. Only directories
which exist at the time will be included.
I work in an environment where linking of dynamic libraries are restricted to certain locations. When I use RStudio and request a new C++ file I get the "Hello World" template. When I try to compile that and link that in by clicking on "Source" in RStudio, I get an error:
LoadLibrary failure: Access is denied.
This error is because the library was located in a space which is not allowed to be able to load DLL files. To maneuver around this limitation, I would like to determine how to tell RCpp to place the temporary dll's (not in a package) in a specific location.
I know that Dirk has suggested that this is not in the scope of RCpp and that all code should live in packages, but that will not be he most user friendly environment for the users here. I suspect that most will use RStudio projects with GIT.
So, that being said, is there an environment variable that I can mangle to get RCpp to place temporary dll files in a specific place. Or is there some other mechanism which I can use to alter this?
Try setting TMPDIR which R respects. This is indeed not an Rcpp issue but a generic R CMD build / R CMD INSTALL issue.
From help(tempfile):
The environment variables TMPDIR, TMP and TEMP are checked in
turn and the first found which points to a writable directory is
used: if none succeeds /tmp is used.
PS Rcpp with lower-case C.
Question: How do I move all of the most up-to-date R packages into one simple location that R (and everything else) will use from now and forever for my packages?
I have been playing around with R on Ubuntu 10.04 using variously RGedit, RCmdr, R shell, and RStudio. Meanwhile, I have installed packages, updated packages, and re-updated packages via apt, synaptic, install.packages(), etc... which apparently means these packages get placed everywhere, and (with the occasional sudo tossed in) with different permissions.
Currently I have different versions of different (and repeated) packages in:
/home/me/R/i486-pc-linux-gnu-library/2.10
/home/me/R/i486-pc-linux-gnu-library/2.14
/home/me/R/i486-pc-linux-gnu-library/
/usr/local/lib/R/site-library
/usr/lib/R/site-library
/usr/lib/R/library
First - I'm a single user, on a single machine - I don't want multiple library locations, I just want it to work.
Second - I am on an extremely slow connection, and can't keep just downloading packages repeatedly.
So - is there an easy way to merge all these library locations into one simple location? Can I just copy the folders over?
How do I set it in concrete that this is and always will be where anything R related looks for and updates packages?
This is maddening.
Thanks for your help.
Yes, it should almost work to just copy the folders over. But pre-2.14 packages WITHOUT a NAMESPACE file probably won't work in R 2.14 where all packages must have a namespace...
And you'd want to manually ensure you only copy the latest version of each package if you have multiple versions...
If you type .libPaths(), it will tell you where R looks for packages. The first in the list is where new packages are typically installed. I suspect that .libPaths() might return different things from RStudio vs. Rcmd etc.
After piecing together various bits of info here goes: A complete moron's guide to the R packages directory organization:
NB1 - this is my experience with Ubuntu - your mileage may vary
NB2 - I'm a single user on a single machine, and I like things simple.
Ubuntu puts anything installed via apt, or synaptic in:
/usr/lib/R/site-library
/usr/lib/R/library
directories. The default vanilla R install will try install packages here:
/usr/local/lib/R/site-library
Since these are system directories the user does not have write privileges to, depending on what method you are interacting with R you might be prompted with a friendly - "Hey buddy - we can't write there, you want us to put your packages in your home directory?" which seems innocent and reasonable enough... assuming you never change your GUI, or your working environment. If you do, the new GUI / environment might not be looking in the directory where the packages were placed, so won't find them. (Most interfaces have a way for you to point where your personal library of packages is, but who wants to muck about in config files?)
What seems to be the best practice for me (and feel free to correct me if I'm wrong) with a default install setup on Ubuntu, is to do any package management from a basic R shell as sudo: > sudo R and from there do your install.packages() voodoo. This seems to put packages in the usr/local/lib/R/site-library directory.
At the same time, update.packages() will update the files in /usr/lib/R/site-library and usr/lib/R/library directories, as well as usr/local/lib/R/site-library
(As for usr/lib/R/ division, it looks like /library/ has the core packages, while /site-library/ holds anything added, assuming they were installed by apt...)
Any packages previously installed and in the wrong place can be moved to the /usr/local/lib/R/site-library directory (assuming you are sudoing it) just by moving the directories (thanks #Tommy), but as usr/lib/R/ is controlled by apt - best not add or subtract anything from there...
Whew. Anyway - simple enough, and in simple language. Thanks everyone for the help.
Does R have a dependency management tool to facilitate project-specific dependencies? I'm looking for something akin to Java's maven, Ruby's bundler, Python's virtualenv, Node's npm, etc.
I'm aware of the "Depends" clause in the DESCRIPTION file, as well as the R_LIBS facility, but these don't seem to work in concert to provide a solution to some very common workflows.
I'd essentially like to be able to check out a project and run a single command to build and test the project. The command should install any required packages into a project-specific library without affecting the global R installation. E.g.:
my_project/.Rlibs/*
Unfortunately, Depends: within the DESCRIPTION: file is all you get for the following reasons:
R itself is reasonably cross-platform, but that means we need this to work across platforms and OSs
Encoding Depends: beyond R packages requires encoding the Depends in a portable manner across operating systems---good luck encoding even something simple such as 'a PNG graphics library' in a way that can be resolved unambiguously across systems
Windows does not have a package manager
AFAIK OS X does not have a package manager that mixes what Apple ships and what other Open Source projects provide
Even among Linux distributions, you do not get consistency: just take RStudio as an example which comes in two packages (which all provide their dependencies!) for RedHat/Fedora and Debian/Ubuntu
This is a hard problem.
The packrat package is precisely meant to achieve the following:
install any required packages into a project-specific library without affecting the global R installation
It allows installing different versions of the same packages in different project-local package libraries.
I am adding this answer even though this question is 5 years old, because this solution apparently didn't exist yet at the time the question was asked (as far as I can tell, packrat first appeared on CRAN in 2014).
Update (November 2019)
The new R package renv replaced packrat.
As a stop-gap, I've written a new rbundler package. It installs project dependencies into a project-specific subdirectory (e.g. <PROJECT>/.Rbundle), allowing the user to avoid using global libraries.
rbundler on Github
rbundler on CRAN
We've been using rbundler at Opower for a few months now and have seen a huge improvement in developer workflow, testability, and maintainability of internal packages. Combined with our internal package repository, we have been able to stabilize development of a dozen or so packages for use in production applications.
A common workflow:
Check out a project from github
cd into the project directory
Fire up R
From the R console:
library(rbundler)
bundle('.')
All dependencies will be installed into ./.Rbundle, and an .Renviron file will be created with the following contents:
R_LIBS_USER='.Rbundle'
Any R operations run from within this project directory will adhere to the project-speciic library and package dependencies. Note that, while this method uses the package DESCRIPTION to define dependencies, it needn't have an actual package structure. Thus, rbundler becomes a general tool for managing an R project, whether it be a simple script or a full-blown package.
You could use the following workflow:
1) create a script file, which contains everything you want to setup and store it in your projectd directory as e.g. projectInit.R
2) source this script from your .Rprofile (or any other file executed by R at startup) with a try statement
try(source("./projectInit.R"), silent=TRUE)
This will guarantee that even when no projectInit.R is found, R starts without error message
3) if you start R in your project directory, the projectInit.R file will be sourced if present in the directory and you are ready to go
This is from a Linux perspective, but should work in the same way under windows and Mac as well.