[Rd] Package inclusion in R core implementation

Duncan Murdoch murdoch@dunc@n @end|ng |rom gm@||@com
Mon Mar 4 15:39:54 CET 2019

On 04/03/2019 7:59 a.m., Jim Hester wrote:
> Conversely, what is the process to remove a package from core R? It seems
> to me some (many?) of the packages included are there more out of
> historical accident rather than any technical need to be in the core
> distribution. Having them as a core (or recommended) package makes them
> harder update independently to R and makes testing, development and
> contribution more cumbersome.

You are conflating base and recommended packages.  Base packages can't 
be updated independently of R because they provide or make use of R 
internals, so they couldn't be distributed separately.  The list of base 
packages is

  [1] "base"      "compiler"  "datasets"  "graphics"  "grDevices" "grid" 
      "methods"   "parallel"  "splines"   "stats"     "stats4"
[12] "tcltk"     "tools"     "utils"

The other packages distributed with R are recommended packages:

  [1] "boot"       "class"      "cluster"    "codetools"  "foreign" 
"KernSmooth" "lattice"    "MASS"       "Matrix"     "mgcv"
[11] "nlme"       "nnet"       "rpart"      "spatial"    "survival"

Those ones have no particular connection to the internals, but they are 
distributed with R, and suffer through somewhat more rigorous testing 
than most contributed packages.  Some of them are used in R's own tests. 
  They can be updated at any time, but their authors are asked not to 
update them near R releases.  In many cases (but not all) their current 
maintainers are R Core members.

In answer to your question and Morgan's:  the process is completely 
opaque.  R Core will add or remove a package if they think it makes 
sense from their point of view.  Generally that happens very rarely, 
because it can be a lot of work, and usually there's not much to be gained.

> On Fri, Mar 1, 2019 at 4:35 AM Morgan Morgan <morgan.emailbox using gmail.com>
> wrote:
>> Hi,
>> It sometimes happens that some packages get included to R like for example
>> the parallel package.
>> I was wondering if there is a process to decide whether or not to include a
>> package in the core implementation of R?
>> For example, why not include the Rcpp package, which became for a lot of
>> user the main tool to extend R?
>> What is our view on the (not so well known) dotCall64 package which is an
>> interesting alternative for extending R?
>> Thank you
>> Best regards,
>> Morgan
>>          [[alternative HTML version deleted]]
>> ______________________________________________
>> R-devel using r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
> 	[[alternative HTML version deleted]]
> ______________________________________________
> R-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

More information about the R-devel mailing list