[Rd] upgrading an R installation to next versoin

[Gabor Grothendieck]

On 7/6/05, Uwe Ligges <ligges at statistik.uni-dortmund.de> wrote:
> 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

Thanks.  This is useful to know.   At the same time the (unstated) philosophy
of the batchfiles is that no environment variables need to be explicitly set in
your system other than ones that are required by the package-making 
tools themselves (Perl, MiKTeX).    Also the existence
of R_PROFILE is nice but does not fully address the point I made since it
still requires that you set R_PROFILE. With the point I was
making nothing at all would have to be done.

There is also some question as to whether one wants the same *.site 
files for all versions of R on the system.  The way the batch files currently 
work is that each R version on your system can have its own *.site files 
although that is a potential disadvantage of my suggestion too.

I will think this over but will likely modify the batch files to incorporate
your idea so that they temporarily set R_PROFILE for the duration of their 
run if not already set.  This would simplify the procedure in that one would
not have to run Rrefresh.bat when the *.site files change (but would
still have to run it to update MiKTeX when a new version of R was installed).

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

Again this is an extra step by the user and it pollutes the system with
yet another environment variable.  Currently the makepkg.bat sets it
for the duration of the build/check/install (unless it was already set).

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

No one need use my setup but it does have the advantage of simplicity.
One can use a vanilla MiKTeX install avoiding significant potential complexity
in using MiKTex, no environment variables need to be set in your system 
other than those needed by the tools themelves and one does not have to do 
any reconfiguration each time one installs a new version of R other than
just run Rrefresh.bat without arguments.  In fact with the addition of the
R_PROFILE idea it will likely work OK even if you forget that step since
it only updates MiKTeX and MiKTeX files probably have not changed 
on a typical new R version anyway.  Also the batch files include Rfind.bat
which locates the various tools needed by R package developers which
helps organize oneself.

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

and, of course, I explained why would want to.  In particular since obviously
this had no impact let me point out that not only is this desirable for one's
own work so that partially done files do not affect the check and install
but it is also desirable when one is working on a package in a group
communicating via svn.  In that case its easiest if one just shares the package
source and can label the incomplete files via .Rbuildignore and share them via 
svn but not have them affect the check and install. 

Its likely that .Rbuildignore is being used for multiple unanticipated
purposes here (those discussed by Martin and those by myself) and one
either needs the flag/switch I suggested or perhaps a more powerful
facility that ecompasses these multiple uses.