I would hope CRAN would let this in with some validation (even to the point of it possibly adding a new field to DESCRIPTION). It may never run on Slolaris or Plan 9, and I - who now runs a CRAN mirror in the hopes to eventually have a MacBuilder equivalent service at some point in the near future - would also appreciate not having to support large scale library & database dependencies, even for a potentially useful package like this. The inclusion in CRAN make packages like it usable in situations where (for example) github packages would not be (my previous employer did not allow non-CRAN packages to be used in sensitive data applications).
On Mon, Apr 18, 2016 at 5:16 PM, Oliver Keyes <ironho...@gmail.com> wrote: > Good day, > > I've written an Rcpp-backed R package > (https://github.com/Ironholds/poster) that interfaces with the > libpostal (https://github.com/openvenues/libpostal) library, written > in C. > > While the two play together perfectly nicely, the problem is > submitting the package to CRAN: libpostal is not a common dependency > and isn't available in a debianised form for CRAN's testing: the > alternative approach, including libpostal *in* the R package, is made > impossible since it downloads gigabyte-sized databases for internal > use. > > What's the approach or guidance on submitting packages in this state? > The package includes a configuration script that recognises (in a > user-friendly way) when dependencies aren't met, and warns the user > appropriately, but it is still ultimately an R package that will not > compile on CRAN. Can it be submitted, albeit with installation > skipped, or is this unacceptable? > > Best, > Oliver > > ______________________________________________ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel