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.onkel...@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 < vincentvanh...@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@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > [[alternative HTML version deleted]] ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
