[Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony

[Henrik Bengtsson]

I (as well) keep a specific Rsetup.bat file for launching Windows
cmd.exe with the proper PATH etc setup for build R packages etc.  It's
only after this thread I gave it a second thought; you can indeed
temporarily set the PATH via ~/.Rprofile or ~/.Renviron, which *are*
processed at the very beginning when calling 'R CMD ...'.

EXAMPLE WITH .Rprofile:

## ~/.Rprofile (e.g. C:/User/foo/.Rprofile):
path <- unlist(strsplit(Sys.getenv("PATH"), ";"));
path <- c("C:\\Rtools\\bin", "C:\\Rtools\\gcc-4.6.3\\bin", path);
Sys.setenv("PATH"=paste(unique(path), collapse=";"));

## DISABLED:
x:\> R --no-init-file CMD INSTALL matrixStats_0.6.2.tar.gz
* installing to library 'C:/Users/hb/R/win-library/3.0'
* installing *source* package 'matrixStats' ...
** libs
*** arch - i386
ERROR: compilation failed for package 'matrixStats'
* removing 'C:/Users/hb/R/win-library/3.0/matrixStats'

## ENABLED:
x:\> R CMD INSTALL matrixStats_0.6.2.tar.gz
* installing to library 'C:/Users/hb/R/win-library/3.0'
* installing *source* package 'matrixStats' ...
** libs
*** arch - i386
gcc -m32 -I"C:/PROGRA~1/R/R-3.0.0patched/include" -DNDEBUG [...]
[...]
* DONE (matrixStats)


EXAMPLE WITH .Renviron:
## ~/.Renviron (e.g. C:/User/foo/.Renviron):
# Backslashes are preserved iff put within quotes
PATH="C:\Rtools\bin;C:\Rtools\gcc-4.6.3\bin;${PATH}"

x:\> R --no-environ CMD INSTALL matrixStats_0.6.2.tar.gz
=> fails

x:\> R CMD INSTALL matrixStats_0.6.2.tar.gz
=> works

As long as R is on the PATH, the above either of the approaches
removes the need to add Rtools to the PATH via a BAT file and it won't
clutter up your PATH.  This begs the question (as somewhat already
proposed), instead of users/developers doing this manually, would it
be possible to have 'R CMD ...' to locate add Rtools to the PATH
internally.  That would certainly lower the barriers for newcomers to
install packages from source that need compilation.  Obviously, this
doesn't make the tools (e.g. make) in Rtools available outside of R,
it does not allow you to build R itself from source, but it does cover
the very common use cases of calling 'R CMD build/INSTALL/check/...'.

/Henrik

PS. Hadley, is this what you meant when you wrote "Better solutions
(e.g. Rstudio and devtools) temporarily set the path on when you're
calling R CMD *.", or those approaches are only when you call 'R CMD'
from the R prompt?  I believe the latter, but I just want to make sure
I didn't miss something.



On Sun, Apr 21, 2013 at 11:02 AM, Gabor Grothendieck
<ggrothendieck at gmail.com> wrote:
> On Sun, Apr 21, 2013 at 12:57 PM, Hadley Wickham <h.wickham at gmail.com> wrote:
>>>>> Because it can conflict with other Windows software unless you add a
>>>>> layer over it.  What other popular software that runs on Windows has
>>>>> these problems?  I can't think of any.  The closest I can come up with
>>>>> was that for a short time after git was ported to Windows it would
>>>>> change the font of the Windows console but there was an immediate hue
>>>>> and cry about it having no business messing with the rest of Windows
>>>>> and it was quickly rectified.
>>>>
>>>> I don't understand: unless you modify settings in the default install,
>>>> Rtools *does not* affect other windows software in any way.
>>>
>>> If its the case that it now works from the cmd line without setting
>>> the Rtools path before issuing R CMD ... that would be great. If so it
>>> must have occurred silently at some point since I have spent hours in
>>> past years trying to track down why another program I was using did
>>> not work only to discover that it was Rtools.  Surely this was also
>>> your own understanding since devtools, maintains an Rtools path
>>> database which ought to be unnecessary if R is able to find Rtools
>>> itself.
>>
>> I think we are having a failure of communication: Rtools does not set
>> the path, so that you must do so, every time you use it. There is no
>> other way to prevent it from interfering from some other windows
>> software, except by tightly confining the scope in which it enters the
>> path. When I first starting working with Rtools, I thought this was a
>> terribly frustrating decision - why didn't the default installer
>> always put rtools on the path? But now I see it's the only way - it
>> avoids conflicts with other software, and without that default there'd
>> be no way to have multiple versions of rtools installed. That said, I
>> think the logic that Rstudio and devtools uses to find rtools would
>> have been helpful to include in base R, but that's not so important
>> now that it's available in a package. (And if any big change was made,
>> I'd probably argue it'd be better just to always bundle rtools with R
>> on windows - I think it's a key part of the philosophy of R that users
>> can easily become developers. But there are obviously other
>> considerations.)
>>
>> To clarify, the rtools database in devtools does not contain a list of
>> locations of rtools, but the directories inside of an rtools
>> installation that need to be available on the path. This list has
>> changed over time as the tools needed by R have changed. I don't see
>> any way of avoiding that (except perhaps by storing those in the
>> registry, but regardless there's no way to go back in time and fix old
>> decisions). Devtools (following the logic of rstudio) looks in a
>> number of places to find rtools, first looking in the path and then in
>> the registry, and takes considerable care to ensure that the versions
>> of R and rtools match (another reason why the database is necessary).
>
> Yes, that is what I thought until you seemed to be saying otherwise
> but it seems we just misunderstood each  other and, in fact,  no one
> disputes the need to put Rtools on the path nor that it conflicts with
> other Windows programs and potentially causes other programs on your
> PC not to work.  In fact that was one of the motivations I had for
> developing the batchfiles as I once spent hours tracking down a
> problem due to Rtools.
>
> Also I understand that the devtools database uses relative paths and
> wasn't faulting devtools for this but only pointing out that the
> database's existence was a consequence of the need to set up the paths
> in the first place which is what we were discussing - not devtools.
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel