Use of R_PROFILE.R / install.R

Prof Brian Ripley writes:

According to R-exts:

  The second purpose for @file{install.R} is to hold code that needs
  to be executed each time the package is attached, after the image is
  loaded.  Few packages have a need for such code so @file{install.R}
  is normally an empty file.

  The optional file @file{R_PROFILE.R} is executed before the code in
  the @file{R} subdirectory and should be used to set up an
  environment needed only to evaluate the code (which is run with the
  @option{--vanilla} command-line flag).  Very few packages will need
  such code.  Indeed, both @file{install.R} and @file{R_PROFILE.R}
  should be viewed as experimental; the mechanism to execute code
  before attaching or installing the package may change in the near
  future.

(Actually it's during loading, not attaching, a namespace, for packages
with namespaces.)

Looking on CRAN, it seems that two packages use R_PROFILE.R for
`options(echo=FALSE)', which does not do anything useful AFAICS.  A
non-empty install.R is used for

require(methods)
require(boot)
require("Hmisc")
data(Wcrit.R)

and that's not the intention (and in particular require() should have its 
return value checked!) -- this is best done in .First.lib/.onLoad.

One problem is that the package has no way to prevent a saved image being 
forced with INSTALL --save.

Since this mechanism is a maintenance nightmare (especially with
lazy-loading +/- saving images) I propose we drop it for 2.0.0.
Instead, just as for lazy-loading, we should have a field in the
DESCRIPTION file, with

SaveImage: yes

forcing saving the image, and any other value forcing not saving it.

Note that most packages which currently save an image probably want to 
use lazy-loading instead and so should have LazyLoad: yes in their 
DESCRIPTION file.

The proposed change is not backwards compatible but affects very few CRAN 
packages, for all of which there is better solution that is backwards 
compatible.  I have not looked at BioConductor or elsewhere, so please 
will package authors let us know of any examples where R_PROFILE.R or 
install.R is essential (and why).

-- 
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 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595

Prof Brian Ripley writes:

According to R-exts:

  The second purpose for @file{install.R} is to hold code that needs
  to be executed each time the package is attached, after the image is
  loaded.  Few packages have a need for such code so @file{install.R}
  is normally an empty file.

  The optional file @file{R_PROFILE.R} is executed before the code in
  the @file{R} subdirectory and should be used to set up an
  environment needed only to evaluate the code (which is run with the
  @option{--vanilla} command-line flag).  Very few packages will need
  such code.  Indeed, both @file{install.R} and @file{R_PROFILE.R}
  should be viewed as experimental; the mechanism to execute code
  before attaching or installing the package may change in the near
  future.

(Actually it's during loading, not attaching, a namespace, for packages
with namespaces.)

Looking on CRAN, it seems that two packages use R_PROFILE.R for
`options(echo=FALSE)', which does not do anything useful AFAICS.  A
non-empty install.R is used for

require(methods)
require(boot)
require("Hmisc")
data(Wcrit.R)

and that's not the intention (and in particular require() should have its 
return value checked!) -- this is best done in .First.lib/.onLoad.

One problem is that the package has no way to prevent a saved image being 
forced with INSTALL --save.

Since this mechanism is a maintenance nightmare (especially with
lazy-loading +/- saving images) I propose we drop it for 2.0.0.
Instead, just as for lazy-loading, we should have a field in the
DESCRIPTION file, with

SaveImage: yes

forcing saving the image, and any other value forcing not saving it.

Fine with me.

Can we perhaps agree to allow both yes/no and true/false for such
logical package DESCRIPTION metadata (and also irrespective of case)?