[R-pkg-devel] Guidance on splitting up an R package?

[Thierry Onkelinx]

Dear Vincent,

Have a look at the spatstat package which was split into several smaller
packages (https://github.com/spatstat/spatstat). Maybe the maintainers of
that package can share some insights.

Best regards,

ir. Thierry Onkelinx
Statisticus / Statistician

Vlaamse Overheid / Government of Flanders
INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE AND
FOREST
Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance
thierry.onkelinx using inbo.be
Havenlaan 88 bus 73, 1000 Brussel
www.inbo.be

///////////////////////////////////////////////////////////////////////////////////////////
To call in the statistician after the experiment is done may be no more
than asking him to perform a post-mortem examination: he may be able to say
what the experiment died of. ~ Sir Ronald Aylmer Fisher
The plural of anecdote is not data. ~ Roger Brinner
The combination of some data and an aching desire for an answer does not
ensure that a reasonable answer can be extracted from a given body of data.
~ John Tukey
///////////////////////////////////////////////////////////////////////////////////////////

<https://www.inbo.be>


Op di 4 okt. 2022 om 16:46 schreef Vincent van Hees <
vincentvanhees using gmail.com>:

> 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
>

	[[alternative HTML version deleted]]