R devel - Apr 2013 - R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony

Having finally found some free time, I was going to use it to update a 
bunch of R packages from 2.15 to 3.0.

I am running Windows 7, 64-bit professional.  This is on a brand-new 
laptop using vanilla settings when installing the operating system.

Problem 1: I installed R3.0 to the default location (C:\Program 
FIles\R\R-3.0.0).  The first thing I tried to do was install 
BioConductor.  This failed (permission denied). Thinking that this might 
be a BioConductor problem, I then tried to install a (semirandom) 
package from CRAN.  This also failed.

In both cases, when using the GUI, the error message is almost 
incomprehensible.  You get a pop-up window that *only* says "Do you want 
to use a private library instead?"  Since this wasn't what I wanted to 
do I said "no".  Only after the pop-up closes does the command window 
print the error message telling me that permission was denied for R to 
write to its own library location.

Dumb Fix to Problem 1: So, I uninstalled R and then reinstalled to a 
nonstandard location (C:\R\R-3.0.0).  Now I can successfully install 
packages from CRAN and BioConductor (hooray!). But I run directly into:

Problem 2: Emacs Speaks Statistics (ESS) can no longer find the R 
binary. When R was installed in the default location, ESS worked. When R 
2.15 (or earlier) was installed in the same nonstandard location, I 
could get ESS to find the R binaries by including (setq 
ess-directory-containing-r "C:") in my .emacs file, but that no longer
works.

Dumb Fix to Problem 2:  Hack into ess-site.el and put the complete, 
explicit path to the correct binary into
(setq-default inferior-R-program-name 'FULLPATHHERE")
which will break as soon as I upgrade R (assuming I am foolish enough to 
ever do that again).


Now I am ready to rebuild my R packages.  I have this nice perl script 
that goes through the following procedure:

1. Set the path to include the correct Rtools directory.  (For reasons 
that Gabor Grothendieck has pointed out previously, this is not a 
permanent part of the path since doing so would override some built-in 
Windows commands.)
2. Build a source tarball via
     R CMD build $package
3. Build a Windows binary version (as a zip file) via
     R CMD INSTALL --build $tarball
4. Check the package via
     R CMD check --as-cran $tarball
5. Install the package via
     R CMD INSTALL $tarball

Problem 3: Step 3 fails, withe the error message "Running 'zip'
failed".

Dumb Fix to Problem 3: Install the GnbuWin32 version of zip, and make 
sure that its location is earlier in ter path than the version that 
comes with Rtools.

Problem 4: Step 4 fails when running the test scripts that accompany the 
package.  The error message is the semicryptic
     "cannot open file 'c:\Users\krc\AppData\Local\Temp\Rtmp....' 
Permission denied"

Dumb Fix to Problem 4: Write this email message and hope someone with 
even more patience than I have has already found a better way to get all 
this stuff to work.

Tired of spinning my wheels,
     Kevin

On 13-04-19 5:37 PM, Kevin Coombes wrote:
> Having finally found some free time, I was going to use it to update a
> bunch of R packages from 2.15 to 3.0.
>
> I am running Windows 7, 64-bit professional.  This is on a brand-new
> laptop using vanilla settings when installing the operating system.
>
> Problem 1: I installed R3.0 to the default location (C:\Program
> FIles\R\R-3.0.0).  The first thing I tried to do was install
> BioConductor.  This failed (permission denied). Thinking that this might
> be a BioConductor problem, I then tried to install a (semirandom)
> package from CRAN.  This also failed.
>
> In both cases, when using the GUI, the error message is almost
> incomprehensible.  You get a pop-up window that *only* says "Do you
want
> to use a private library instead?"  Since this wasn't what I
wanted to
> do I said "no".  Only after the pop-up closes does the command
window
> print the error message telling me that permission was denied for R to
> write to its own library location.
This is a standard Windows problem, to stop viruses from modifying 
installed programs.  The standard Windows solution to it is to run the 
installer as an administrator, taking personal responsibility for 
installing the package/virus.

Since this is a laptop, you could probably do this, but it's possible 
that you are not the administrator on your system.  If that's the case, 
you should ask your administrator to do the install.
>
> Dumb Fix to Problem 1: So, I uninstalled R and then reinstalled to a
> nonstandard location (C:\R\R-3.0.0).  Now I can successfully install
> packages from CRAN and BioConductor (hooray!). But I run directly into:
That's another solution, and a third solution is to accept the offer R 
made, to install your packages somewhere where you as a user have write 
permission.
>
> Problem 2: Emacs Speaks Statistics (ESS) can no longer find the R
> binary. When R was installed in the default location, ESS worked. When R
> 2.15 (or earlier) was installed in the same nonstandard location, I
> could get ESS to find the R binaries by including (setq
> ess-directory-containing-r "C:") in my .emacs file, but that no
longer
> works.
>
> Dumb Fix to Problem 2:  Hack into ess-site.el and put the complete,
> explicit path to the correct binary into
> (setq-default inferior-R-program-name 'FULLPATHHERE")
> which will break as soon as I upgrade R (assuming I am foolish enough to
> ever do that again).
I can't help you with ESS.
>
>
> Now I am ready to rebuild my R packages.  I have this nice perl script
> that goes through the following procedure:
>
> 1. Set the path to include the correct Rtools directory.  (For reasons
> that Gabor Grothendieck has pointed out previously, this is not a
> permanent part of the path since doing so would override some built-in
> Windows commands.)
Just curious:  how often do you use the Windows find command?  We have 
put instructions in place for people to run the install process with a 
renamed Rtools find command (which I think is the only conflict). The 
issue is that more users who want to use the command line commands are 
familiar with the Unix variant (which came first, by the way) than the 
Windows one, so renaming the Rtools one would cause trouble for more people.
> 2. Build a source tarball via
>       R CMD build $package
> 3. Build a Windows binary version (as a zip file) via
>       R CMD INSTALL --build $tarball
> 4. Check the package via
>       R CMD check --as-cran $tarball
> 5. Install the package via
>       R CMD INSTALL $tarball
>
> Problem 3: Step 3 fails, withe the error message "Running
'zip' failed".
>
> Dumb Fix to Problem 3: Install the GnbuWin32 version of zip, and make
> sure that its location is earlier in ter path than the version that
> comes with Rtools.
I have no idea about this one.
>
> Problem 4: Step 4 fails when running the test scripts that accompany the
> package.  The error message is the semicryptic
>       "cannot open file
'c:\Users\krc\AppData\Local\Temp\Rtmp....'
> Permission denied"
That's Windows permissions biting you again.  Run as administrator.

Duncan Murdoch
> Dumb Fix to Problem 4: Write this email message and hope someone with
> even more patience than I have has already found a better way to get all
> this stuff to work.
>
> Tired of spinning my wheels,
>       Kevin
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

While as a Linux user who has not so far been banished to Winland I have 
not experienced this problem, it seems to be the type of issue where a 
"how to", for example, on the R Wiki, would be helpful. Moreover,
surely
this is a name conflict on different platforms, so possibly a list of 
these in a related location would also be useful. I have been struggling 
unsuccessfully to remember one that bit me recently when I did have to 
help a Windows user. It was not a major disaster, but more of a large 
sucking sound of time being wasted figuring out something that was just 
a shade more than trivial.

If there are folk who can get this started, do include me in an off-list 
copy and I'll be willing to test/edit wiki material.

JN