I have observed that R installation in Windows creates two library paths automatically.
.libPaths()
# [1] "C:/Users/User/Documents/R/win-library/3.4"
# [2] "C:/Program Files/R/R-3.4.0/library"
What is the use of these while installing new packages and which library is used? I have frequently observed the installed packages being missed and need to install again. How do you maintain these two paths and manage the libraries while using R or RStudio in Windows?
Installing into C:/Program Files/R/... makes a package available to all users of the computer.
It is the R default, but installing a package there from within R (using install.packages() requires that R is started with administrator privileges.
Installing into C:/Users/Username/... makes the package available to the present user only, but does not require administrative rights.
R tracks these paths automatically, and looks in both directories when it is asked to load a package with require() or library(). No user input should be required.
When you update R, the version number will of course change, meaning that R will no longer look in the folders whose paths contained the previous version number. Some R updaters (e.g. installR) offer to copy packages from the "old" paths to the "new" paths, though an manually re-installing packages means that you can be sure that you are using the latest version of each package, and that you don't waste disk space and update time on packages that you are no longer using.
Related
I am trying to copy R packages from a directory on one linux server and install them on another. I started out by writing a script that would loop through a list of all the R packages I needed and install them. This worked for a majority of packages, but, since I am forced to utilize R 3.0.3, a significant number of packages are unavailable for this version of R. Meaning that R was trying to install the most recent versions of these specific packages.
I am trying to find a solution that does not involve me having to go through each package, find the version we are running on the old server, then going to CRAN and downloading the archived .tar.gz file.
Ideally, I would like to loop through the directory of R packages, make them all into .tar.gz files, move those files to the new server, and install them like that. However, I ran into the following issue when I tried to "build" one these packages.
R CMD build car
Read 1 item
* checking for file ‘car/DESCRIPTION’ ... OK
* preparing ‘car’:
* checking DESCRIPTION meta-information ... OK
Warning in file(con, "r") :
cannot open file 'man': No such file or directory
Error in file(con, "r") : cannot open the connection
ERROR
computing Rd index failed
I tried another using devtools::build('abind'), but this also failed with the same errors above.
Should I change my approach or is there something missing with what I am doing? Any help on this would be appreciated.
Your general approach won't work: tar.gz files contain the source for a package, but not all of it is installed when you install a package, so you can't recreate the tar.gz file from the installed files.
What might work if you didn't want to work with such an ancient version of R is to use Microsoft's CRAN "time machine" (https://mran.microsoft.com/timemachine), but I think it only goes back to R 3.2.3.
Copying the library might work, but binaries of those files are probably linked to system library files at particular locations, so I wouldn't trust it to be reliable.
I think your best option would be to update R to the current release (or maybe 3.5.3, the last patch release of the previous series), then just install current versions of the packages you want.
If this is impossible for some reason, then you're likely to have no choice but installing versions matching the ones you had installed. At least you can find versions automatically: the installed.packages() function returns a matrix with package name in column "Package" and its version in column "Version". Run that on the old system, then build them on the new system using the remotes::install_version() function (which claims to work on R back to 3.0.0, but I bet it hasn't been tested there lately).
I just need to solve a problem with my RStudio. I have the lastest version on both R & RStudio, but every time that I reboot the PC ad open the program it tells me that some packages are not installed. After several times I have noticed that the problematic packages are: stringi, MASS, survival or Rcpp.
Also if I have to install another package which depends on them a warning appears saying that the packages mentioned are not updated, and it gives me the option to update all.
I tried to reinstall them and enter as an admin in RStudio but nothing works so, does anyone know what is happening here? Thanks for your help.
R packages are installed into libraries. The location of libraries searched by R is determined by the value of .libPaths(). Likely you have the problematic packages installed in more than one library; check for the same package installed in both dir(.libPaths()[1]) and dir(.libPaths()[2]), for instance.
Use remove.packages() with the lib= argument to remove one installation.
My practice is to install R and base packages only in the default library (possibly as administrator), and to install all other packages in a library that I as a regular user have access to. The personal library is the first entry in .libPaths(), which is the default location for package installation. See ?.libPaths for how to set up libraries; all library paths have to exist, else R silently drops them from .libPaths(). I use a setting in ~/.Renviron. Thus
> .libPaths()
[1] "/home/mtmorgan/R/x86_64-pc-linux-gnu-library/3.5-Bioc-3.8" # personal
[2] "/home/mtmorgan/bin/R-3-5-branch/library" # base
> sapply(.libPaths(), function(path) length(dir(path)))
/home/mtmorgan/R/x86_64-pc-linux-gnu-library/3.5-Bioc-3.8
236
/home/mtmorgan/bin/R-3-5-branch/library
30
This question already has answers here:
installation path not writable R, unable to update packages
(9 answers)
Closed 2 years ago.
I installed the Bioconductor packages on R version 3.1.2 on Ubuntu 14.04 and received the message below:
The downloaded source packages are in
‘/tmp/RtmpZYw0Qp/downloaded_packages’ Warning message: installed
directory not writable, cannot update packages 'boot', 'class',
'KernSmooth', 'mgcv', 'nnet', 'rpart', 'spatial'
What does it mean, and how does it affect using the above packages on R?
I faced the same problem working in R-studio. The solution is to give root access to R.
In Windows, that means you need to run the program as an Administrator.
In Unix/Linux, you should launch R from the terminal by doing sudo R.
Then, once you're running with sufficient privileges, you can try installing your package and it should work.
The warning means that there are more recent versions of the listed packages available, but your version cannot be updated because the directory in which the packages are installed cannot be written to. Usually this means that R was installed with 'system administrator' privileges, but that you are trying to update packages as a regular user.
The consequence is that the features or bug fixes implemented in the updated packages are not available to you. The specific consequences could range from minor typographical corrections on a man page through serious bug fixes. Qualitatively, my bet is that it 'does not matter' for most uses.
The solution is to update these packages when running R as a user with permission to write to packages in the installed directories -- typically the last element of the output of .libPaths(), or more fine-grained via installed.packages()[, "LibPath"]
I faced the same problem today when installing three Bioconductor packages under Windows. Two (dependencies of the package I really wanted) were already on my system in newer forms (as described in #Martin-Morgan solution) and so no action was necessary. However, one was not installed. For this, third package, I had success in doing an installation from the local file that was downloaded during the failed install without having to escalate privileges (which was my next step as outlined by #Ninadmw).
In R, go to the menu Packages/Install Package(s) from local files and navigate to the local download directory listed, which in your case was /tmp/RtmpZYw0Qp/downloaded_packages, and select the package you want to install.
In RStudio (which you should use), go to the menu Tools\Install Packages, change the install from field to Package Archive File (.zip; .tar.gz), use Browse... to navigate to the listed download directory, which in your case was /tmp/RtmpZYw0Qp/downloaded_packages and select the package you want to install. Then click on the Install button.
For over a year now, I've been afraid to update my version of R for fear of losing the "rgdal" package...which when I first started working with R on my mac (and maybe still?), had to be installed from source/ could not be installed via the package installer from within R. That was complicated and I had to seek help from a more experienced R user than myself in order to get this package which is critical for me.
But I've finally decided that I need to take the risk and update R. I used the following instructions:
#--run in the old version of R
setwd("C:/Temp/")
packages <- installed.packages()[,"Package"]
save(packages, file="Rpackages")
Followed by this in the new version:
#--run in the new version
setwd("C:/Temp/")
load("Rpackages")
for (p in setdiff(packages, installed.packages()[,"Package"]))
install.packages(p)
found in this post:
Painless way to install a new version of R?
This seems to have worked (e.g. I can open up libraries that aren't included in the base install...including rgdal) but I have the following questions in order to better understand this whole process:
1) Is it the case that in following this approach, I essentially saved a list of all the R packages I had previously installed in my old version, then (from within the new version) determined the SET of packages that differed from the set of base libraries in the new version and told R to install packages belonging to this SET?
2) If the above is true, then does this approach negate the need to update my packages after (e.g. by installing them from within the new version, the newest versions are installed)?
3) The other approach that seems to be common out there (and that is recommended in one of the responses to the post above) is to set up things so that all packages get saved to a directory outside of R and then change the settings (in the .Renviron file or whatever the appropriate file is) to always look for packages in this external directory... I'm wondering why this approach is favoured by some people? Is it because this approach means that after updating R everything is just ready to go (e.g. if one is willing to work with un-updated packages)? I'm confused because if one still has to use update.packages() after installing a new version of R, doesn't this just more or less amount to re-installing them? What are the advantages?
4) Are there packages that I need to worry about if I do go the install route (and not the save to external directory then update route)? R did give me a warning that indicates that four of my packages are not available for the latest version (R. 3.0.3). I'm assuming that if I need to use these packages, I must temporarily just revert to an older version of R. Is this all correct?
Thank you in advance for the help!
1) Yes.
2) The newly installed packages will be at the latest version, but there is no harm in running update.packages(ask=FALSE, checkBuilt=TRUE) afterward just be be sure everything is up to date.
3) I've not seen anyone suggest this particular approach, though a similar process is suggested in the R for Windows FAQ that consists of 1) installing the new version 2) copying the packages from the library folder of the old version to the library folder of the new version and 2) running update.packages(checkBuilt=TRUE, ask=FALSE). I don't think there are any clear advantages to doing it this way vs. the installed.packages()... way.
4) All methods under discussion are limited to CRAN packages, so things that you installed from e.g., bioconductor will not be covered. Also packages removed from CRAN will not be covered, you will either have to use an older version of R or build and install them manually.
I am developing a framework for reproducible computing with R. One problem that I am struggling with is that some R code might run perfectly in version X.Y-Z of a package, but then why you try to reproduce it 3 years later, the packages have updated, some functions are changed, and the code doesn't run anymore. This problem affects also for example Sweave documents that use packages.
The only way to confidently reproduce the results is by installing the R version and version of the packages that were used by the original author. If this was a single case, one could pull stuff from the CRAN archives and install appropriate versions. But for my framework this is impractical, and I need to have the package versions preinstalled.
Assume for now that I restrict myself to a single version of R, e.g. 2.14. What would be a practical way to install many versions of R packages, so that I can load them on the fly? I suppose I can do something like creating separate library directories for every version of every package and then using custom lib.loc arguments while loading them. This is going to be messy though. Any tips or previous attempts to do something similar?
My framework runs on Ubuntu server.
You could install packages with versions (e.g. rename to foo_1.0 directory instead of foo) and softlink the versions you want to re-create a given R + packages snapshot into one library. Obviously, the packages could actually live in a separate tree, so you could have library.projectX/foo -> library.all/foo/1.0.
The operating system gives you even more handles for complete separation, and the Debian / Ubuntu stack as a ton of those available. Two I have played with are
chroot environments: We use this to complete separate build environments from host machines. For example, all Debian uploads I produced are built in a i386 pbuilder chroot hosted on my amd64 Ubuntu server. Chroot is a very powerful Unix system call. Chroots, and particularly the pbuilder system built on top of it (for Debian package building) are meant to operate headless.
Virtual machines: This gives you full generality. My not-so-powerful box easily handles three virtual machines: Debian i386, Ubuntu i386 as well as Windoze XP. For this, I currently use KVM along with libvirt; this is Linux specific. I have also used VirtualBox and VMware in the past.
I would try to modify the DESCRIPTION file, and change the field "Package" there by adding the version number.
For example, you download the package source a from CRAN page (http://cran.r-project.org/web/packages/pls/). Unpack the compressed file (pls_2.3-0.zip) to a directory ("pls/"). The following steps are to change the package name in DESCRIPTION ("pls/DESCRIPTION") and installation with R command 'R CMD INSTALL pls/', where 'pls/' is a path to the package source with modified DESCRIPTION file.
Playing with R library paths seems a dangerous thing to me.