Re: [Rd] upgrading an R installation to next versoin
On 6/30/2005 8:10 AM, Gabor Grothendieck wrote: > When I install a new version of R (Windows XP) I have to: > > 1. copy my rw\etc\Rprofile.site file to the new installation > > 2. copy the rw\share\texmf files to the tex subfolder of the >miktex root directory and then refresh the miktex name database >(I have a batch file that does this for me which I run >whenever I install a new version of R.) > > 3. setup the shortcut key using 'properties' on my R desktop icon so >that ctrl-alt-R brings up the new rather than the old R. (This one >really had me confused once since I did not realize I was still >using the old version of R after installing the new one.) > > 4. reinstall the packages I use or else setup etc\Renviron.site with >an R_LIBS to point to include the old library or perhaps one can >copy the libraries over being careful not to overwrite new versions >of the standard libraries. > > Many other windows program automatically transfer the settings when > you upgrade them. > > I wonder if the installation process could optionally transfer > such settings from an old installation to a new one to make it > easier to install R. I think a couple of these could be handled by not applying so many modifications to the R installation, do more locally. For example, #1 needn't be copied, you can just use the R_ENVIRON environment variable to point to it and both versions will see it. I'd call #2 a bug in MikTeX, but it's probably one we'll have to work around one of these days. (The bug is dropping support for the environment variable specification of extra include directories.) #3 might be something we could do, but I don't see how. The installer could know what hotkey you used the last time you installed R, but if you changed it in the meantime, how would it know about that? And how would it remove the hotkey from the old shortcut? (A little experimentation suggests that XP is buggy in handling multiple shortcuts with the same hotkey. I'd rather stay away from this.) #4 is another case where you can put your libraries outside R_HOME. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] upgrading an R installation to next versoin
On 6/30/05, Duncan Murdoch <[EMAIL PROTECTED]> wrote: > On 6/30/2005 8:10 AM, Gabor Grothendieck wrote: > > When I install a new version of R (Windows XP) I have to: > > > > 1. copy my rw\etc\Rprofile.site file to the new installation > > > > 2. copy the rw\share\texmf files to the tex subfolder of the > >miktex root directory and then refresh the miktex name database > >(I have a batch file that does this for me which I run > >whenever I install a new version of R.) > > > > 3. setup the shortcut key using 'properties' on my R desktop icon so > >that ctrl-alt-R brings up the new rather than the old R. (This one > >really had me confused once since I did not realize I was still > >using the old version of R after installing the new one.) > > > > 4. reinstall the packages I use or else setup etc\Renviron.site with > >an R_LIBS to point to include the old library or perhaps one can > >copy the libraries over being careful not to overwrite new versions > >of the standard libraries. > > > > Many other windows program automatically transfer the settings when > > you upgrade them. > > > > I wonder if the installation process could optionally transfer > > such settings from an old installation to a new one to make it > > easier to install R. > > I think a couple of these could be handled by not applying so many > modifications to the R installation, do more locally. For example, #1 > needn't be copied, you can just use the R_ENVIRON environment variable > to point to it and both versions will see it. > > I'd call #2 a bug in MikTeX, but it's probably one we'll have to work > around one of these days. (The bug is dropping support for the > environment variable specification of extra include directories.) > > #3 might be something we could do, but I don't see how. The installer > could know what hotkey you used the last time you installed R, but if > you changed it in the meantime, how would it know about that? And how > would it remove the hotkey from the old shortcut? (A little > experimentation suggests that XP is buggy in handling multiple shortcuts > with the same hotkey. I'd rather stay away from this.) > > #4 is another case where you can put your libraries outside R_HOME. > > Duncan Murdoch > I am not too fond of cluttering up my system with environment variables but do have an idea for one one partial measure that might be considered. If the installation kept track of the previous installation by putting the installation path of the previous installation somewhere (probably the registry but maybe a file or an environment variable) then it would be possible for the user to write a batch file or even an R routine that copied information from the previous installation to the current one. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] upgrading an R installation to next versoin
Gabor Grothendieck wrote: > When I install a new version of R (Windows XP) I have to: > > 1. copy my rw\etc\Rprofile.site file to the new installation > > 2. copy the rw\share\texmf files to the tex subfolder of the >miktex root directory and then refresh the miktex name database >(I have a batch file that does this for me which I run >whenever I install a new version of R.) > > 3. setup the shortcut key using 'properties' on my R desktop icon so >that ctrl-alt-R brings up the new rather than the old R. (This one >really had me confused once since I did not realize I was still >using the old version of R after installing the new one.) > > 4. reinstall the packages I use or else setup etc\Renviron.site with >an R_LIBS to point to include the old library or perhaps one can >copy the libraries over being careful not to overwrite new versions >of the standard libraries. > > Many other windows program automatically transfer the settings when > you upgrade them. > > I wonder if the installation process could optionally transfer > such settings from an old installation to a new one to make it > easier to install R. I install each new version of R to a directory ...\R\rcurrent (first renaming the previous rcurrent directory to its "official" name rw). Having set up the shortcut key one time, on subsequent installations I tick the installer's checkbox "Don't create a Start Menu folder". I keep a separate directory ...\R\library for nonstandard packages, with environment variable R_LIBS set to the directory name. My miktex.ini file specifies ...\R\rcurrent\share\texmf as a place to look for input files. 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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] upgrading an R installation to next versoin
On 6/30/05, J. Hosking <[EMAIL PROTECTED]> wrote: > Gabor Grothendieck wrote: > > When I install a new version of R (Windows XP) I have to: > > > > 1. copy my rw\etc\Rprofile.site file to the new installation > > > > 2. copy the rw\share\texmf files to the tex subfolder of the > >miktex root directory and then refresh the miktex name database > >(I have a batch file that does this for me which I run > >whenever I install a new version of R.) > > > > 3. setup the shortcut key using 'properties' on my R desktop icon so > >that ctrl-alt-R brings up the new rather than the old R. (This one > >really had me confused once since I did not realize I was still > >using the old version of R after installing the new one.) > > > > 4. reinstall the packages I use or else setup etc\Renviron.site with > >an R_LIBS to point to include the old library or perhaps one can > >copy the libraries over being careful not to overwrite new versions > >of the standard libraries. > > > > Many other windows program automatically transfer the settings when > > you upgrade them. > > > > I wonder if the installation process could optionally transfer > > such settings from an old installation to a new one to make it > > easier to install R. > > I install each new version of R to a directory ...\R\rcurrent (first > renaming the previous rcurrent directory to its "official" name rw). That's a good idea -- always using the same folder name for R. > Having set up the shortcut key one time, on subsequent installations > I tick the installer's checkbox "Don't create a Start Menu folder". > > 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 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. 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. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] upgrading an R installation to next versoin
Gabor Grothendieck wrote: > On 6/30/05, J. Hosking <[EMAIL PROTECTED]> 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. > Jon Hosking __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] upgrading an R installation to next versoin
On 6/30/05, J. Hosking <[EMAIL PROTECTED]> wrote: > Gabor Grothendieck wrote: > > On 6/30/05, J. Hosking <[EMAIL PROTECTED]> 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. > > > > Jon Hosking > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] upgrading an R installation to next versoin
On 6/30/05, J. Hosking <[EMAIL PROTECTED]> wrote: > Gabor Grothendieck wrote: > > On 6/30/05, J. Hosking <[EMAIL PROTECTED]> 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. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] upgrading an R installation to next versoin
Duncan Murdoch stats.uwo.ca> writes: > On 6/30/2005 8:10 AM, Gabor Grothendieck wrote: > > When I install a new version of R (Windows XP) I have to: > > > > 1. copy my rw\etc\Rprofile.site file to the new installation Same here, and I also change one or two things in etc/Rconsole. It would be nice if we could tell to keep 'site-wide' config files outside of $R_HOME (which is always version-number challenged, ie. the path changes four times a year [ assuming two regular releases with one patch releases each, as has been the norm lately ] ). So just as I can set R_LIBS in ~/.Renviron to point to my library directory, would it make sense to add, say, R_ETC ? > > 2. copy the rw\share\texmf files to the tex subfolder of the > >miktex root directory and then refresh the miktex name database > >(I have a batch file that does this for me which I run > >whenever I install a new version of R.) I have no issues with the tetex installation in Cygwin. > > 3. setup the shortcut key using 'properties' on my R desktop icon so > >that ctrl-alt-R brings up the new rather than the old R. (This one > >really had me confused once since I did not realize I was still > >using the old version of R after installing the new one.) I ignore the icons, so I don't care. But I always need to update my softlink farm in /usr/local/bin for R, Rgui, Rterm, Rcmd. > > 4. reinstall the packages I use or else setup etc\Renviron.site with > >an R_LIBS to point to include the old library or perhaps one can > >copy the libraries over being careful not to overwrite new versions > >of the standard libraries. > > > > Many other windows program automatically transfer the settings when > > you upgrade them. > > > > I wonder if the installation process could optionally transfer > > such settings from an old installation to a new one to make it > > easier to install R. As Duncan mentioned, this one is easy to take care of. I use R_LIBS="c:/opt/R/lib" in ~/.Renviron, and that directory is outside of / parallel to where I install the different R versions. One idea I had was if we could ask the installer to (optionally) adopt a scheme different from rw/ and to simple use something like Rcurrent/, with an optional renaming of the previous R installation to Rprevious. That way, Gabor's desktop icon doesn't need to change, nor do my softlinks in /usr/local/bin have to be adapted, as they always point into Rcurrent/bin/ . I am probably overlooking something. But in case I don't, would anybody else see merit in this scheme? Regards, Dirk __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] upgrading an R installation to next versoin
On 6/30/05, Gabor Grothendieck <[EMAIL PROTECTED]> wrote: > On 6/30/05, J. Hosking <[EMAIL PROTECTED]> wrote: > > Gabor Grothendieck wrote: > > > On 6/30/05, J. Hosking <[EMAIL PROTECTED]> 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. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] upgrading an R installation to next versoin
Gabor Grothendieck wrote: > On 6/30/05, Gabor Grothendieck <[EMAIL PROTECTED]> wrote: > >>On 6/30/05, J. Hosking <[EMAIL PROTECTED]> wrote: >> >>>Gabor Grothendieck wrote: >>> On 6/30/05, J. Hosking <[EMAIL PROTECTED]> 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 wo
Re: [Rd] upgrading an R installation to next versoin
On 7/6/05, Uwe Ligges <[EMAIL PROTECTED]> wrote: > Gabor Grothendieck wrote: > > > On 6/30/05, Gabor Grothendieck <[EMAIL PROTECTED]> wrote: > > > >>On 6/30/05, J. Hosking <[EMAIL PROTECTED]> wrote: > >> > >>>Gabor Grothendieck wrote: > >>> > On 6/30/05, J. Hosking <[EMAIL PROTECTED]> 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 packa
Re: [Rd] upgrading an R installation to next versoin
I have been thinking a bit more about the Windows R installation upgrade discussion below and there are really two cases: 1. one wants to upgrade R and is no longer interested in preserving the old versions of R In this case one could configure R to have a ..\R\library folder that contains the library and *.site files so that they do not have to be moved each time that one upgrades R. (The old versions of R still access the same library and *.site files as the new versions of R and over time its likely that they won't work any more with the old versions of R as we start using the features of the newer R but in this case we don't really care.) The problem here is that the defaults do not support this and one must set environment variables which complicates setup. I have some batch files which will automatically set them although if R would automatically: 1. look into ...\R\library if it cannot find ...\R\rw...\library and 2. look for ...\R\etc\*.site if it cannot find them in ...\R\rw...\etc\*.site this could be streamlined substantially. The only danger in supporting this is that anyone who used this facility would not be preserving the identity of different versions on his system -- although that is already true if they use R_PROFILE, etc. since that applies to all versions too. 2. one wants to upgrade R but wants to maintain the old versions in working order. In this case we need to snapshot the library and *.site files so we might as well keep them in a version-specific area, viz. ...\R\rw...\library and ...\R\rw...\etc\*.site and then copy them over to the new version of R when that new version is installed (so that as they change over time with the new version the old version of R still has its older ones). Thus I would suggest that we: 1. by default search for ..\R\library and \R\*.site if those are not otherwise found 2. have an option to allow or disallow the installation program to copy over *.site and library files from the old version to the new version (or else provide registry information on what the old and new versions are so that one can write a program to do it oneself) On 6/30/05, Duncan Murdoch <[EMAIL PROTECTED]> wrote: > On 6/30/2005 8:10 AM, Gabor Grothendieck wrote: > > When I install a new version of R (Windows XP) I have to: > > > > 1. copy my rw\etc\Rprofile.site file to the new installation > > > > 2. copy the rw\share\texmf files to the tex subfolder of the > >miktex root directory and then refresh the miktex name database > >(I have a batch file that does this for me which I run > >whenever I install a new version of R.) > > > > 3. setup the shortcut key using 'properties' on my R desktop icon so > >that ctrl-alt-R brings up the new rather than the old R. (This one > >really had me confused once since I did not realize I was still > >using the old version of R after installing the new one.) > > > > 4. reinstall the packages I use or else setup etc\Renviron.site with > >an R_LIBS to point to include the old library or perhaps one can > >copy the libraries over being careful not to overwrite new versions > >of the standard libraries. > > > > Many other windows program automatically transfer the settings when > > you upgrade them. > > > > I wonder if the installation process could optionally transfer > > such settings from an old installation to a new one to make it > > easier to install R. > > I think a couple of these could be handled by not applying so many > modifications to the R installation, do more locally. For example, #1 > needn't be copied, you can just use the R_ENVIRON environment variable > to point to it and both versions will see it. > > I'd call #2 a bug in MikTeX, but it's probably one we'll have to work > around one of these days. (The bug is dropping support for the > environment variable specification of extra include directories.) > > #3 might be something we could do, but I don't see how. The installer > could know what hotkey you used the last time you installed R, but if > you changed it in the meantime, how would it know about that? And how > would it remove the hotkey from the old shortcut? (A little > experimentation suggests that XP is buggy in handling multiple shortcuts > with the same hotkey. I'd rather stay away from this.) > > #4 is another case where you can put your libraries outside R_HOME. > > Duncan Murdoch > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
