From ligges at statistik.uni-dortmund.de  Wed Jul  6 23:12:24 2005
From: ligges at statistik.uni-dortmund.de (Uwe Ligges)
Date: Wed, 06 Jul 2005 23:12:24 +0200
Subject: [Rd] upgrading an R installation to next versoin
In-Reply-To: <971536df05070605244d022d9e@mail.gmail.com>
References: <971536df0506300510f6d6ac2@mail.gmail.com>	<da15bn$1r5$1@sea.gmane.org>	<971536df05063012166bfa590b@mail.gmail.com>	<da1jlv$et5$1@sea.gmane.org>	<971536df050630152014c8f70@mail.gmail.com>
	<971536df05070605244d022d9e@mail.gmail.com>
Message-ID: <42CC4938.6050605@statistik.uni-dortmund.de>

Gabor Grothendieck wrote:

> On 6/30/05, Gabor Grothendieck <ggrothendieck at gmail.com> wrote:
> 
>>On 6/30/05, J. Hosking <jh910 at juno.com> wrote:
>>
>>>Gabor Grothendieck wrote:
>>>
>>>>On 6/30/05, J. Hosking <jh910 at juno.com> wrote:
>>>>
>>>
>>>...
>>>
>>>
>>>>>I keep a separate directory ...\R\library for nonstandard packages,
>>>>>with environment variable R_LIBS set to the directory name.
>>>>
>>>>
>>>>Do you mean your R_LIBS has two components: one to look in
>>>>..\R\rcurrent\library and a second to look in ..\R\library? What does
>>>>it look like exactly?
>>>>
>>>>When you do install.packages(whatever) does it install to the
>>>>..\R\library rather than ..\R\rcurrent\library ?   Also, does
>>>>updates.packages() work as expected for you?
>>>>
>>>
>>>My R_LIBS environment variable is just
>>>
>>>  R_LIBS=C:\progs\r\library
>>>
>>>and within R I see
>>>
>>>  > .libPaths()
>>>  [1] "C:/progs/r/library"          "C:/progs/r/rcurrent/library"
>>>
>>>i.e., the default library is automatically appended.  The help for
>>>.libPaths explains this.  And yes, install.packages() installs to
>>>C:\progs\R\library and update.packages() works as expected.
>>>
>>>
>>>>>My miktex.ini file specifies ...\R\rcurrent\share\texmf as a place
>>>>>to look for input files.
>>>>
>>>>
>>>>I think its necessary to rebuild the name data base in miktex too
>>>>    initexmf -u
>>>>although ignoring that step may work as long as the filenames
>>>>have not changed.
>>>
>>>You are probably correct, though I have not yet encountered any problems
>>>that I could attribute to not running initexmf -- no doubt the filenames
>>>have not changed recently.
>>>
>>>
>>>>I was hoping to continue using a vanilla
>>>>miktex installation as I do now rather than having a custom miktex.ini
>>>>file.  At any rate my batch file would continue to work even with your setup
>>>>so I think I should be ok here.
>>>>
>>>>
>>>>
>>>>>That should take care of your points 3, 4, and 2, respectively.
>>>>>Duncan's suggestion of an R_ENVIRON environment variable (which
>>>>>I didn't know about; thanks, Duncan) should take care of point 1.
>>>>>
>>>>>Jon Hosking
>>>>
>>>>
>>>>It occurs to me in reading this that I could keep the *.site files in
>>>>..\R and then have my miktex update batch file also copy them
>>>>to the appropriate etc folder.  Thus keeping an R\library folder
>>>>and running the batch file after each new installation would
>>>>address 1, 2 and 4 even without using the same name for the
>>>>rw... folder.  This still does not handle the shortcut key which
>>>>I would have to handle manually or determine if there is a way
>>>>I could also add that to my batch file.
>>>>
>>
>>Thanks. I think I have it now.  I have:
>>
>>- placed my *.site files and library folder in C:\Program Files\R
>> and have set the R_LIBS variable in Renviron.site to point to
>> C:\Program Files\R\library .
>>
>>- I have a batch file which I placed on my desktop which runs rgui.exe
>> from the bin subfolder of the current version of R (using the registry
>> entry to find it).  That desktop shortcut has the Alt+Ctrl+R shortcut
>> key associated with it since the batch file itself does not change even
>> when I install new versions of R.
>>
>>- each time I install a new version of R I run a batch file which
>> -- copies the R miktex files to the appropriate miktex folder
>> -- refreshes the miktex file name data base
>> -- copies the *.site files in \Program Files\R to the etc subfolder
>>    of the current version of R (using the registry entry to find it)
>>
>>Getting this right is something I have been putting off for some time
>>now since I was very concerned that I screw up my entire R installation
>>but with the advice of the two of you I think I have it now.
>>If any of this functionality could be taken over by the standard
>>R installation procedure that would be great but in any case I think
>>I have a solution that works for me now.  Thanks.
>>
> 
> 
> I have cleaned up my batch files (somewhat) and posted them to 
> CRAN. See my recent post:
>    https://www.stat.math.ethz.ch/pipermail/r-help/2005-July/073400.html
> 
> If any of this functionality could migrate to R itself that would be great.
> 
> 1. In particular, if R could automatically look in ../R for *.site files if it
> can't find them in .../R/rw..../etc and if it could look for a library

This is already implemented, just specify the environment variable 
R_PROFILE which points to your global site file. See ?Startup


> in .../R/library then Rrefresh.bat could be simplified to just refreshing
> MiKTeX and makepkg.bat would not have to set the R_LIBS variable.

Well, same as above, just set R_LIBS. You can do this for all sessions 
by using the windows control panel, you don't need to do it in each session.

Why do you expect others are using a setup like yours?
I do not. And I do not want R to look


> 2. Also if Rcmd CHECK and Rcmd INSTALL were to process .Rbuildignore
> like Rcmd BUILD does then makepkg.bat would not have to do a build first.

Martin already pointed out why you should not really want this.

Uwe


> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



[Rd] upgrading an R installation to next versoin
Uwe Ligges