RFC: Loading packages at startup

[Robert Gentleman]

A not unrelated idea is to supply user settable hooks for save and
load. Which I am slowly working on.
When objects are saved we can probe them for their classes and then 
insert code into the saved image that will attempt to reload the
appropriate libraries when the image (or XDR file) is reloaded.
There will be a user interface to add other functions etc.

It might be worth thinking about the ability to manipulate Rpackages
objects from within R. Eg, a user can view, add or remove functions
(or expressions). 
I think making the elements function calls will give you more flexibility
in the long run.
In some ways patterning it along the lines of
on.exit may lead to less confusion.
On the otherhand, simply listing the packages is likely to be easiest.
Even in that case it would be nice to let the user have some control 
short of editing files.



On Tue, Oct 22, 2002 at 10:57:41AM +0200, Friedrich.Leisch@ci.tuwien.ac.at wrote:
> 
> Brian,
> 
> Sounds great to me! I use something much simpler to emulate exactly
> that feature using .First and .Last
> 
> >>>>> On Mon, 21 Oct 2002 21:24:45 +0100 (GMT Daylight Time),
> >>>>> Prof Brian D Ripley (PBDR) wrote:
> 
>   > I've been kicking the following idea around for a while, and am now
>   > proposing to put some version into 1.7.0.  I'd be interested in
>   > comments on the desirability and the design, before I start writing
>   > any code.
> 
> 
> 
>   > S4 introduced a file .S.chapters which can contain a list of S
>   > chapters (equivalent to R packages) to be loaded on start-up.  This
>   > was the germ of this proposal.
> 
>   > Proposal:
> 
>   > Extend the initialization as described in Startup.Rd by having
>   > optionally files named, say, R_HOME/etc/Rpackages.site and .Rpackages,
>   > the latter in the starting directory or failing that the user's home
>   > directory. Each would contain a list of packages, one per line, to be
>   > loaded when R is started, in the order in the files.
> 
>   > Some details:
> 
> [...]
> 
> 
>   > 3) It would be useful to allow the library tree to be specified, as a
>   >    second field on the line.
> 
> Or simply use paths? e.g.,
> 
> foo
> /path/to/bar
> 
> could be read as
> 
> require(foo)
> require(bar, lib="/path/to")
> 
> 
>   > 4) One problem with saving an R session and then restoring it is that
>   >    the packages in use are not reloaded.  Quitting an R session and
>   >    saving could write .Rpackages in the current directory (with the
>   >    library recorded if it were not the default).  Then restarting a
>   >    session in that directory would restore the loaded packages
>   >    automatically.
> 
> Yes, I do that for quite some time now (though my hacks were never
> foolproof enough for public consumption).
> 
>   > 5) We might want to allow a .Rpackages file to override Rpackages.site
>   >    (or we might not).
> 
> I think merging is better than overriding, especially in the light of
> 6.
> 
>   >    One idea is to allow a minus sign in front of a
>   >    package name, and to merge the Rpackages.site and .Rpackages files
>   >    before loading any packages.  If we did this we probably need to be
>   >    able to save the list of packages to be loaded (and can't easily save
>   >    those not to be loaded), so perhaps -- as the first list of .Rpackages
>   >    should empty the list.
> 
> Sounds good, so lines starting with a minus sign are persistent and
> the others get modified upon saving?
> 
> 
> 
>   > 6) One could argue for R_HOME/etc/Rpackages as the `system' file as
>   >    well, and this might be useful if we break base up into smaller
>   >    components.
> 
>   > 7) I would allow comment lines in the files, starting with #.
> 
> yes
> 
>   > 8) The file names or names could be set by environment variables.  It's
>   >    strange that we allow the site file names for Rprofile and Renviron and
>   >    the user file name for command histories to be set in that way.
> 
> Hmm, do we really need to be able to modify those? Makes writing docs
> and debugging harder ...
> 
> Best,
> Fritz
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
> r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
> Send "info", "help", or "[un]subscribe"
> (in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
> _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

-- 
+---------------------------------------------------------------------------+
| Robert Gentleman                 phone : (617) 632-5250                   |
| Associate Professor              fax:   (617)  632-2444                   |
| Department of Biostatistics      office: M1B20
| Harvard School of Public Health  email: rgentlem@jimmy.dfci.harvard.edu   |
+---------------------------------------------------------------------------+
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._