Ensure all vignettes are not in packages but only shown in the website. Or, use a bookdown where each chapter is dedicated to a package.
consider limiting fgeo's job to loading fgeo-packages already intalled. That is, users may install each of the probably frew packages they need, then load them all with library(fgeo).
Sean's idea is a good one: To reduce the numer of core packages that install with fgeo. All packages may be loaded with library(fgeo) including non-core ones.
Check the actual size of each package and try keep it under 1MB -- the size for CRAN. Maybe each package will carry its own little datasets for examples and tests, so fgeo.data isn't a dependency.
Submit packages to CRAN?
Extract out functions for general dataset and submit to CRAN. Keel the fgeo-specific ones on GitHub?
Remove dependencies that are not stricly necessary: e.g. fgeo.tool uses bciex for tests but I could use it only locally.
Ensure all vignettes are not in packages but only shown in the website. Or, use a bookdown where each chapter is dedicated to a package.
consider limiting fgeo's job to loading fgeo-packages already intalled. That is, users may install each of the probably frew packages they need, then load them all with
library(fgeo)
.Sean's idea is a good one: To reduce the numer of core packages that install with fgeo. All packages may be loaded with
library(fgeo)
including non-core ones.Check the actual size of each package and try keep it under 1MB -- the size for CRAN. Maybe each package will carry its own little datasets for examples and tests, so fgeo.data isn't a dependency.
Submit packages to CRAN?
Extract out functions for general dataset and submit to CRAN. Keel the fgeo-specific ones on GitHub?
Remove dependencies that are not stricly necessary: e.g. fgeo.tool uses bciex for tests but I could use it only locally.