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 <e...@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 <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. > > 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 | e...@debian.org ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
