I would also be interested in knowing what the rationale is for this. Moreover, it seems that the "standard" (and documented) approach to this of calling "options(defaultPackages=c(...))" in ~/.Rprofile does not get ignored when installing. The environment variable approach may work, but it seems to me that this requires some (educated) guesswork. Could R CMD INSTALL not ignore the default packages option?
Regards, Jon On 16 February 2011 17:25, Brian G. Peterson <br...@braverock.com> wrote: > On 02/16/2011 10:57 AM, Prof Brian Ripley wrote: >> >> The most obvious answer is not to do that. You have not used the >> standard mechanism to to do that (which should work here as R CMD >> INSTALL overrides that one). It's all in ?Startup (look for >> R_DEFAULT_PACKAGES). > > Note that R CMD INSTALL is not mentioned at all here. > >> The simplest way to ignore ~/.Rprofile is to set R_PROFILE_USER to >> something else. > >>> I've tried R --vanilla CMD INSTALL, but that seems to have no effect. >> >> As documented. > > Then let's try this from another angle... > > Is there a rationale why --vanilla or --no-environ or --no-site-file or > --no-init-file are *NOT* supported by R CMD INSTALL ? I don't see any > reasoning for the inconsistency in the docs anywhere. > > If not, would R-core entertain a patch that would handle these options? > > This functionality is troublesome in a production installations where we > *want* our users to have specific packages and environment options set all > the time, and I need to edit the Rprofile.site file every time I upgrade one > of these 'production' packages. > > Regards, > > - Brian > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
