From ggrothendieck at gmail.com  Wed Jul  6 14:24:49 2005
From: ggrothendieck at gmail.com (Gabor Grothendieck)
Date: Wed, 6 Jul 2005 08:24:49 -0400
Subject: [Rd] upgrading an R installation to next versoin
In-Reply-To: <971536df050630152014c8f70@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>
Message-ID: <971536df05070605244d022d9e@mail.gmail.com>

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
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.

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.



[Rd] upgrading an R installation to next versoin
Gabor Grothendieck