[Rd] Feature request: Change default library path on Windows

[Jeroen Ooms]

On Sun, Jul 25, 2021 at 12:15 AM Steve Haroz <steve.haroz using gmail.com> wrote:
>
> Hello,
>
> I'd like to propose moving the default library install location on Windows from:
> %USERPROFILE%/Documents/R
> to some other location such as:
> %USERPROFILE%/R
>
> For many users the Documents folder is backed up or synchronized.
> Installing libraries thrashes Documents, and it causes synchronization
> issues with Dropbox (I confirm this one), OneDrive, and users with
> Network IT policies.
>
> The vast majority of R users won't touch that folder and don't need it
> backed up. And, its contents are not really "documents".

I very much support this request. R's behavior of defaulting HOME to
an unusual (legacy) directory is also a source of bugs and
interoperability problems:

R packages that interface c/c++ libraries that require a user config
file (libssh, libgit2, etc) sometimes cannot find the user config
because it gets stored on a different location than expected. A good
example is 'git'. The 'git for windows' command line utility stores my
user config in C:\users\Jeroen\.gitconfig. However, for R packages
that link to libgit2 (e.g. git2r, gert) the user config gets
loaded/stored from C:\users\Jeroen\Documents\.gitconfig because
libgit2 inherits the R home directory. Having 2 different git
configurations is obviously confusing for users.

Another problem is that when you start R from "windows bash" or the
msys2 shell (including "git for windows" or rtools40), the "~"
directory is different than in RGui. This is because these shells do set
the HOME variable (to the usual value), and R inherits that.

For example: when I start R in RGui for Windows I see:

  > normalizePath("~")
  [1] "C:\\Users\\jeroen\\Documents"

But when I start R or Rterm from the "git for windows" shell we get:

  > normalizePath("~")
  [1] "C:\\Users\\jeroen"

An ambiguous home directory is obviously going to break R code that
refers to paths in your home.

Because these problems affect all Windows users, I think the benefits
of fixing the default behavior easily outweigh the
backward-compatibility and "there is a documented workaround"
arguments.