How to Update R Packages in Default Library on Windows 7

Unable to update R packages in default library on Windows 7

Usually you need administrator rights to change things in program files. Try running RGui as administrator.

How do I change the default library path for R packages

See help(Startup) and help(.libPaths) as you have several possibilities where this may have gotten set. Among them are

• setting R_LIBS_USER
• assigning .libPaths() in .Rprofile or Rprofile.site

and more.

In this particular case you need to go backwards and unset whereever \\\\The library/path/I/don't/want is set.

To otherwise ignore it you need to override it use explicitly i.e. via

library("somePackage", lib.loc=.libPaths()[-1])

when loading a package.

Change R default library path using .libPaths in Rprofile.site fails to work

I generally try to keep all of my packages in one library, but if you want to add a library why not append the new library (which must already exist in your filesystem) to the existing library path?

.libPaths( c( .libPaths(), "~/userLibrary") )
 # obviously this would need to be a valid file directory in your OS
 # min just happened to be on a Mac that day

Or (and this will make the userLibrary the first place to put new packages):

.libPaths( c( "~/userLibrary" , .libPaths() ) )

Then I get (at least back when I wrote this originally):

> .libPaths()
[1] "/Library/Frameworks/R.framework/Versions/2.15/Resources/library"
[2] "/Users/user_name/userLibrary"  

The .libPaths function is a bit different than most other nongraphics functions. It works via side-effect. The functions Sys.getenv and Sys.setenv that report and alter the R environment variables have been split apart but .libPaths can either report or alter its target.

The information about the R startup process can be read at ?Startup help page and there is RStudio material at: https://support.rstudio.com/hc/en-us/articles/200549016-Customizing-RStudio

In your case it appears that RStudio is not respecting the Rprofile.site settings or perhaps is overriding them by reading an .Rprofile setting from one of the RStudio defaults. It should also be mentioned that the result from this operation also appends the contents of calls to .Library and .Library.site, which is further reason why an RStudio- (or any other IDE or network installed-) hosted R might exhibit different behavior.

Since Sys.getenv() returns the current system environment for the R process, you can see the library and other paths with:

Sys.getenv()[ grep("LIB|PATH", names(Sys.getenv())) ]

The two that matter for storing and accessing packages are (now different on a Linux box):

R_LIBS_SITE                          /usr/local/lib/R/site-library:/usr/lib/R/site-library:/usr/lib/R/library
R_LIBS_USER                          /home/david/R/x86_64-pc-linux-gnu-library/3.5.1/
 

Some R packages do not update with update.packages()

A general restatement of the question

1. In Windows 7/8 the package nicePack, included in the base install, is outdated.
2. You update it with update.packages() or via the equivalent GUI menu.
3. You get:
   
   Warning: package 'nicePack' in library 'C:/Program Files/R/R-3.*.*/library" will not be updated

Potential causes

R is not very kind with Windows so it just says "will not be updated" and not something like "permission denied to C:/Program Files/R/...". Anyway you realise that R cannot write to C:/Program Files and so restart it as Administrator and upgrade, but the problem persists!

If you check the personal package directory, where R is able to write, you see that the updated version of nicePack is there. In Windows the directory is normally ~\R\win-library\x.y or find it with Sys.getenv("R_LIBS_USER").

Probably the first time R, unable to write to R default directory, used the personal directory, so that there are two versions of nicePack. The second time, despite the admin privileges, R finds the updated package version in the personal directory and it does not update the default directory.

May be that R says "warning" and not "error", because the package is installed in the personal directory, but an outdated version remains in the default library.

Solution

Delete nicePack package directory in the personal library directory, restart as administrator and update again.

Opinions

I don't know if there is an actual bug in this behaviour, anyway more informative messages would for sure help the Windows user.

Perhaps the default library should be avoided in Windows, in favour of the personal. Many Windows applications use C:\ProgramData or ~\AppData\Local, writeable without special privileges.

Make a file writable in order to add new packages

Changing the security setting on the R folder to "full control" fixed this for me. See the third posting down at this link for step by step instructions: Unable to update R packages in default library on Windows 7

Windows 7: Installing multiple R packages via script

The odesolve package is depreciated and has been replaced by deSolve. R 2.15.1 is throwing an error when encountering this package. It could be causing problems for you. Here's a script I use for installing packages for new R installs.

libs=c("CircStats","coda","deldir","gplots","igraph","ks","odesolve‌​","RandomFields")
type=getOption("pkgType")                           
    CheckInstallPackage <- function(packages, repos="http://cran.r-project.org",
       depend=c("Depends", "Imports", "LinkingTo", "Suggests", "Enhances"), ...) {
         installed=as.data.frame(installed.packages())
    for(p in packages) {
        if(is.na(charmatch(p, installed[,1]))) { 
          install.packages(p, repos=repos, dependencies=depend, ...) 
                    }
      }
    } 
    CheckInstallPackage(packages=libs)

Windows 7, update.packages problem: unable to move temporary installation ?

I found that the problem indeed is the antivirus "real time file system protection". I do the following to fix the problem:

trace(utils:::unpackPkgZip, edit=TRUE)

I edit line 140 (line 142 in R 3.4.4):

Sys.sleep(0.5)

to:

Sys.sleep(2)

I seems like the antivirus stalls the creation of the package tmp dir. After changing it to 2 seconds the error is gone.

EDIT: to do this programmatically execute

trace(utils:::unpackPkgZip, quote(Sys.sleep(2)), at = which(grepl("Sys.sleep", body(utils:::unpackPkgZip), fixed = TRUE)))

(credits @DavidArenburg)

---

Related Topics