[Rd] R Startup configuration file

[Duncan Murdoch]

On 12/02/2010 3:50 AM, Barry Rowlingson wrote:
> On Wed, Feb 10, 2010 at 3:06 PM, Barry Rowlingson
> <b.rowlingson at lancaster.ac.uk> wrote:
> 
>>  But I agree that writing a saveable options package is the first step
>> - then making that a default in R is the second so people don't have
>> to edit profiles and R packages and applications can expect an API for
>> savable state.
> 
>  More thinking about this has turned it into a problem of being able
> to serialize R objects to XML. The most reliable way I can find of
> doing that is to use serialize, then rawToChar, and put a big old hex
> string in the XML. Hardly the most user-friendly format, but then
> users aren't supposed to edit XML anyway. I have also considered
> having encoding types for objects, something like:
> 
> <object encoding="raw" name="foo">66f6e.....a7726</object>
> <object encoding="numeric" name="bar">3.141</object>
> <object encoding="numeric" size="2"
> name="baz"><item>3.14</item><item>6.28</item></object>

If you're storing hex, why not just use the binary save() format? (Or 
the save(ascii=TRUE) format.)  What is the advantage of XML?

> at which point I remembered that R objects can also have attributes
> which can be any other R objects too. At which point I realized life's
> too short for this...
> 
> ..and had a rethink. Lots of software these days has a configuration
> directory, and runs all the scripts or configs within - think
> /etc/cron.daily/ or /etc/init.d on a unix system. This has the
> advantage that components of the system can manage their own startup
> files there, and not worry about stomping on others. So you'd have a
> .Rprofile.d/ folder with, say, a cran.R file that could be sourced by
> anything that used CRAN, for example to set the default mirror. I'd
> insist that each file in .Rprofile.d/ started with a "# do not edit
> this file" warning...
> 
>  I'll think some more over coffee until I realise why this is another
> of my dumb ideas...

I see two ways such a thing might be used: everything run at startup, or 
just running things as needed.  Running everything at startup has the 
disadvantage that it requires all sorts of diverse packages to be 
loaded, so running things as needed makes more sense.  But do you really 
want to make it so granular that it depends on the kind of task 
(accessing CRAN, ...)?  Wouldn't it be good enough to have one user init 
file per package, and have it executed when the package is loaded?

Duncan