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: 1) I think the packages should be loaded before .Rprofile and .RData are processed, and R_HOME/etc/Rpackages.site before .Rpackages. This can be argued, and the S4 parallel would seem to be to load packages after S.init (the nearest it has to Rprofile). But we would load library/base/Rprofile first of all so the analogy is not close. 2) The present kludge of loading ctest in .First could be replaced by making ctest the default content of R_HOME/etc/Rpackages.site (in the light of point 5). 3) It would be useful to allow the library tree to be specified, as a second field on the line. 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. 5) We might want to allow a .Rpackages file to override Rpackages.site (or we might not). 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. 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 #. 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. -- Brian D. Ripley, ripley@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272860 (secr) Oxford OX1 3TG, UK Fax: +44 1865 272595 -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- 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 _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
On 21-Oct-02 Prof Brian D Ripley wrote:> [...] > 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.This would certainly be useful, especially (as in (4) below) when resuming an analysis session.> Some details: > [...] > 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.A comment from a practical user's viewpoint. I'm not sure of the value of having this happen automatically. In practice I have a directory for a dataset, only occasionally different sub-directories for different analyses, and several different analyses might be done on that dataset. If the above (4) were implemented as it stands, everything that was ever loaded would be reloaded each time (if I understand right). It would be better, perhaps, to allow flexibility (unless the overhead etc. of loading un-needed packages could be ignored), and I can see two ways: a) Offer a choice at startup between different ".Rpackages.XXX" where "XXX" varies with the job and is mnemonic for the user (i.e. the user chose it in the first place). I think this would also require the implementation to query the user at quit time about what ".Rpackages.XXX" should be called. b) (More complicated and trickier to implement, more transparent perhaps for the user, but maybe demanding too much foresight in the implementation) the ".Rpackages" or equivalent would keep track in some way of dependencies, so that if the user invoked a function which had been used in a previous session, packages needed would be loaded automatically. Best wishes to all, Ted. -------------------------------------------------------------------- E-Mail: (Ted Harding) <Ted.Harding@nessie.mcc.ac.uk> Fax-to-email: +44 (0)870 167 1972 Date: 22-Oct-02 Time: 09:34:49 ------------------------------ XFMail ------------------------------ -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- 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 _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
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 _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
I think the proposed changes will be useful. A couple of points (mostly for simplicity): Prof Brian D Ripley wrote:> ... > > 3) It would be useful to allow the library tree to be specified, as a > second field on the line.Other than convenience (nothing wrong with that, of course) I don't see too much need for this. The .Renviron files may already have defined R_LIBS, so the library tree may already be specified.> ... > > 5) We might want to allow a .Rpackages file to override Rpackages.site > (or we might not). 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.Why not using arguments to R, say, --no-site-Rpackages and --no-Rpackages, similar to --no-environ, --no-site-file, --no-init-file, and friends? Adding specialized syntax with the minus sign seems a bit kludgy. My preferance would be to have R by default include base and only base (or whatever one package is the mimimum set), all other packages (ctest, etc.) as part of the $R_HOME/etc/Rpackages.site, as the RFC point 2) suggests.> > 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 #. > > 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. > > -- > Brian D. Ripley, ripley@stats.ox.ac.uk > Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ > University of Oxford, Tel: +44 1865 272861 (self) > 1 South Parks Road, +44 1865 272860 (secr) > Oxford OX1 3TG, UK Fax: +44 1865 272595 > > > -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- > 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 > _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._-- David A. James Statistics Research, Room 2C-253 Phone: (908) 582-3082 Bell Labs, Lucent Technologies Fax: (908) 582-3340 Murray Hill, NJ 09794-0636 -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- 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 _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
>>>>> Prof Brian D Ripley writes:> 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:> 1) I think the packages should be loaded before .Rprofile and .RData > are processed, and R_HOME/etc/Rpackages.site before .Rpackages. > This can be argued, and the S4 parallel would seem to be to load > packages after S.init (the nearest it has to Rprofile). But we > would load library/base/Rprofile first of all so the analogy is not > close.> 2) The present kludge of loading ctest in .First could be replaced > by making ctest the default content of R_HOME/etc/Rpackages.site > (in the light of point 5).> 3) It would be useful to allow the library tree to be specified, as a > second field on the line.> 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.> 5) We might want to allow a .Rpackages file to override Rpackages.site > (or we might not). 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.> 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 #.> 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.I'd recommend against going this way. In fact, I am not sure whether we really want to have *user environment* files in the long run. We currently have two user files controlling startup, .Renviron and .Rprofile. A split like this is necessary because not all customization for R can be done from 'inside R', i.e., after R has been started, but needs to be done before that. To my understanding, this includes setting LD_LIBRARY_PATH (or the system's equivalent), and maybe some env vars which can be given instead of command line args, but with R_VSIZE and R_HSIZE sort of gone what else is there? So perhaps the user environment mechanism is not the right thing anyway (and it is not used by R CMD *). For the things that can be done from inside R, I'd recommend doing it this way. E.g., there is really no reason for looking for an env var R_BROWSER when we can portably specify one using options(browser). The fact that specifying the packages to be loaded at startup inside .First() and that users cannot simply add to .First() is a problem that needs to be addressed anyway. As Robert has indicated, the obvious idea is to introduce (an Emacs-style) hooks mechanism to be run at certain times, or more generally, when certain events occur. Unfortunately, the attempt to make this rather general, as discussed in Boston, means that things also take a bit longer to get done. But conceptually, what we want is a suite of setHook() addHook() runHooks() functions, and things like .First(), .First.lib() (and the user variants), code to be run when creating a save image etc., can all be integrated into this general mechanism. [Basically, hooks are lists of functions because in some cases we need to call them with certain arguments, e.g. the .First.lib package load hook always has library and package and maybe also version eventually.] For package config, users can then use setHook() to override the system and/or site defaults, or addHook() to add to them. As everything happens inside R there is no need for a special format, as discussed in (3), (5), and (7). [If users cannot be expected to code their preferences in R ... then we could provide an interactive tool which eventually emits the R code.] Long term, startup configuration will include setting defaults, loading packages, perhaps playing namespace magic with some of them, perhaps everything according to predefined 'themes' ... and I'd like to have all of this in one place, if possible. Point (4) is very important, in particular if we think about saving and restoring the 'state' of an R session (as opposed to just the work space). I think many of us (I know from at least Greg, Fritz and myself) have code going in this direction, but then we need more than just names of the packages. We should perhaps also know about attached non-package objects etc. Also, I am not sure about how attempting to load/attach in reverse order will interact with namespace import/export and pre-computing package dependencies before loading them. But in any case, dumping an object that somehow represents the session state would be extremely important---but I do think we need an R object to represent the information. -k -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- 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 _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
On Fri, 25 Oct 2002 09:15:07 +0200, Kurt.Hornik@wu-wien.ac.at wrote in message <15800.61307.451828.338523@mithrandir.hornik.net>:> But in any >case, dumping an object that somehow represents the session state would >be extremely important---but I do think we need an R object to represent >the information.It might be possible at some point to store something that would cause R to fail to start, so if a binary format is used for this file, there should be tools provided to allow it to be edited. This could be as simple as instructions for running "R --vanilla", loading and editing the startup info, and saving it back. Duncan Murdoch -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- 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 _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._