[R-pkg-devel] Guidance on splitting up an R package?
William Revelle
||@t@ @end|ng |rom reve||e@net
Tue Oct 4 21:42:19 CEST 2022
In 2019, I split psych into psych and psychTools to meet the 5MB space restriction. I moved several of vignettes, data sets, and a few helper functions over to psychTools. This mainly allowed for more vignettes but also allows me to add new data sets to psychTools without needing to recompile psych. This is discussed in the news file for psych and psychTools.
Bill
> On Oct 4, 2022, at 9:46 AM, Vincent van Hees <vincentvanhees using gmail.com> wrote:
>
> Dear all,
>
> I am looking for guidance (blog posts / books / people with expertise) on
> how to split up an R package that has grown a lot in complexity and size.
> To make it worthwhile, the split needs to ease the maintenance and ongoing
> development.
>
> Here are my quick reflections on it:
> 1. Where possible try to preserve the consistency of the original R
> package. So, spin-off packages should ideally become helper-packages to the
> original package and tests need to be in place to ensure compatibility of
> the original R package is preserved.
> 2. Keep similar functionality together. For example, a function to read
> files does not have to be in the same package as a function to plot the
> data, but a function to adjust the color coding of the plots should be
> stored near the other plotting functions.
> 3. Try to isolate external dependencies. For example, if dependency Y
> changes I ideally only have to worry about updating one of my R packages to
> it instead of several.
>
> I am wondering whether anyone else has ever made a more elaborate mapping
> of do's and don'ts when it comes to splitting up an R package or any
> software for that matter?
>
> Vincent
>
> [[alternative HTML version deleted]]
>
> ______________________________________________
> R-package-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
More information about the R-package-devel
mailing list