[R-pkg-devel] Submitting CRAN packages with hard-to-meet dependencies
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
Re: [R-pkg-devel] Submitting CRAN packages with hard-to-meet dependencies
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 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
Re: [R-pkg-devel] Submitting CRAN packages with hard-to-meet dependencies
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 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
Re: [R-pkg-devel] Submitting CRAN packages with hard-to-meet dependencies
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 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 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
