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

[boB Rudis]

So, how do we create a solid alternative to CRAN? github drat wld have
been impossible at my previous gig (for good reasons). Is it time to
try to get rOpenSci to be a legit CRAN alternative? Add enough process
around it to support things like this (i.e. a less narrowly focused
Bioconductor)? Package complexities are only going to grow, not
shrink. Such is this brave, new data science world we live in.

On Mon, Apr 18, 2016 at 8:36 PM, Dirk Eddelbuettel <edd at debian.org> wrote:
>
> My $0.02:
>
> On 18 April 2016 at 20:23, boB Rudis wrote:
> | 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).
>
> Won't fly. Wishing and praying alone doesn't make it happen.  You are putting
> the burden on CRAN, and the two of them already have 8270+ packages to look after.
>
> Suggestion below.
>
> | 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.
>
> How about this:
>
>  -- insert a new layer between poster and libpostal which satisfies the
>     build requirements for poster and lets it be installed
>
>  -- the layer intercepts calls, and with libpostal not present alerts the
>     user
>
> So now postal has a wrapper which may come with its own installer support.
>
> | > 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?
>
> No because it won't build so it cannot be tested.  You can do this, but not
> on CRAN.  There is drat ...
>
> Dirk
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org