[R-pkg-devel] Submitting CRAN packages with hard-to-meet dependencies

[boB Rudis]

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 <ironholds at 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 at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel