0

The default R library, .Library, is normally not writeable under Windows. You need to run R as Administrator. For new packages you can set and use a personal library, but this doesn't work when updating packages in the base setup (e.g. by update.packages()).

If you forget (or don't know you need) to run as Administrator, you get duplicate versions of the same packages, messing the installation.

I think one solution could be copying all packages to a personal library and disabling the default one. I know how to add a new library path to R, i.e. .libPaths ("my/path"), but how to remove the default library from .libPaths ()?

Update for non-Windows users

Some clarifications might help mostly non-Windows R users to understand the mentioned problem.

In Windows "Log on as Administrator" (or better as a user belonging to administrators' group) and "Run as Administrator" are quite different things.
In the former case you just give your credentials at logon, much like in Linux; in the latter you are already logged as a "superuser", but in order to carry out a potentially dangerous action, you have to ask an ad hoc permission to Windows (proving that it's you and not a malware acting).

That's said, programs (and developers), before accessing known Windows' protected objects (i.e. C:\Program Files folder), ask permission to the user to avoid being blocked by the OS.
Even when they don't ask (because they assume the knowledgeable user should give this permission in advance), failure to access is normally reported like "Permission denied to access to folder etc.".

As for R version 3.0.2, update.packages() involves one of the situations, where an elevated permission request should be triggered, because this might involve writing to protected program folders. Unfortunately R doesn't ask and cannot update the directory with old packages.

What about the second safe net: user notifications? While install.packages() gives messages like:

stop ... "'lib' element %s is not a writable directory" ...

and you get the idea of a permission problem, with others functions, such as update.packages(), you get:

warning ... "package '%s' in library '%s' will not be updated"

whose causes can be everything.

Can this scenario be even worse? Yes. Besides not asking for permission to write to "Program Folders", besides not issuing a notification of the permission error, update.packages(), when unable to update packages in protected folders, actually installs them to the personal user folder, but without notifying this. This is similar to what install.packages() does, except that the latter notifies and asks permission to do this. So you end up with two versions of the same packages in different folders! Your calculations will be therefore dependent on library priorities.

Can this scenario be even worse? Yes. You are clever (or Google) enough to understand that you need to "Run as Administrator", when you want to update packages. You restart R as Administrator and hope this will fix everything. Not at all. R sees the updated packages in the personal library and does not act. So you remain with two versions of the same packages.
To solve this you have to detect duplicate packages and remove them manually, then restart R as administrator and update again (or write a script to do this).

Clearly the solution would be R conforming to Windows apps expected behaviour, or at least do nothing when prevented to act (instead of taking non-notified decisions).

In the meantime I think that totally disabling the default library (located in a protected area) would be a temporary workaround.

A final note. Packages and package updating are crucial for using R, so my humble opinion is that the topic should deserve specific careful attention even for less GNU-blessed systems like Windows.

antonio
  • 10,629
  • 13
  • 68
  • 136
  • Updating "base packages" is generally done by re-installing. I don't see a reason for "updating" single packages that have "Priority"="base" status. – IRTFM Dec 15 '13 at 21:39
  • @DWin that would mean installing patch releases and you are forgetting Priority "Recommended", where those packages are on CRAN and they are routinely updated between R releases, especially now that R is on a 12-month cycle. – Gavin Simpson Dec 15 '13 at 21:51
  • @Dwin: Recently I ran `update.packages()` and it tried to update some 3.0.2 base packages. I didn't run the command as Admin and got into problems. More here: [Some R packages do not update with update.packages()](http://stackoverflow.com/questions/20587440/) – antonio Dec 15 '13 at 22:42
  • I saw that question. Why would one want to update "graphics"? Furthermore you offered no information about versions (of anything) already installed so one could not really tell what you were doing. – IRTFM Dec 15 '13 at 23:16
  • @Dwin: I don't want to update it in particular, I wanted to keep the the system updated with `update.packages()`. I will update my question with version number, which is 3.0.2 anyway. – antonio Dec 16 '13 at 00:06
  • Please read what the RWIN-FAQ says about installing as administrator and also read what it says about those with non-admin rights: `[1] Non-administrator accounts will automatically be offered a default installation directory in the user area.` If you want to be installed as a non-admin, then you should be able to consolidate your libraries since the R/ directory will have write access. (Seems rather strange to me.) – IRTFM Dec 16 '13 at 01:00

1 Answers1

1

One solution is to change R_LIBS environment variable. You can see for example this question.

But If you don't have admin rights, you can specify location when you load the package:

library(my_package, lib.loc="my/path")
Community
  • 1
  • 1
agstudy
  • 119,832
  • 17
  • 199
  • 261