[Rd] R Startup configuration file

[Duncan Murdoch]

Barry Rowlingson wrote:
> Currently when R starts up it can be configured by a file of
> environment variable specifications and a file of R code. This makes
> programmatic modification of startup configuration tricky.
>
> Case in point: I start R, do install.packages("foo"), and up pops the
> 'choose a CRAN mirror' dialog. I'd like to put a 'Save my choice'
> button on that dialog. Currently it would have to put
> 'options(repos="http://example.com/cran")' into my .Rprofile file. Of
> course my .Rprofile file could be full of all sorts of other code, so
> there's no easy way to do this and guarantee it will work.
>
> Could we have a ".Rconfig" file, consisting of key-value pairs in a
> standard config file form (or XML?), that is read at startup and
> applies the key-value pairs to options(key=value)? Obviously more
> detail is needed, such as whether to just have one .Rconfig file in
> the users' $HOME or in individual folders, where to put a system
> Rconfig file, whether it is applied before or after .Rprofile etc.
>   

When I read the ?Startup man page, I find it is too complicated already; 
I don't want to add another kind of file to read.  (Would we have  
separate user and site versions of this new file?  When would it be 
handled?)

However, we could achieve what you are asking for with no changes to 
base R.  One way would be to write a small package to handle options.  
When you want to save a setting, you call a function there that writes 
it to a private file.  Then you manually add a line to your .Rprofile, 
saying something like "myOptionPackage::loadMyOptions()".  This can do 
whatever you want, it only needs to know how to parse the file that your 
package wrote.

Duncan Murdoch

> Or is it a dumb idea? I can see other ways of doing this, such as
> saving the options() as an object and re-loading it at startup, but a
> config file has the advantage of being simply read-writable by humans
> and computers.
>
> I notice several other package using options-style things that might
> benefit from a simple persistence framework. For example the sm
> package says in ?sm.options:
>
>      This offers the possibility of customizing the functioning of the
>      'sm' library, for instance by insertions of appropriate calls to
>      'sm.options' in a load hook for package 'sm'.
>
> To which the average user goes 'huh what?'. With a config file there
> could be a save.sm.options() function that wrote a new section to the
> user's .RConfig:
>
> [sm]
>  whatever = 99
>  doSomething = TRUE
>
> which the sm package would read in when it is first attached.
>
> My usual R-devel caveats - yes, I know everyone has day jobs; yes, I'm
> sure there are problems with it; no, I don't expect it to get done
> unless someone thinks it's a Good Thing because I probably don't have
> time for it; yes, R is wonderful and fantastic and you devs do a
> fantastic job.
>
> Barry
>
>