I must have missed the bit where anyone mentioned Title Case.
CRAN's rules are definitely solid the vast majority of the time, and I've
opted for a GitHub/devtools based release.
On Wednesday, 20 April 2016, Dirk Eddelbuettel wrote:
>
> On 18 April 2016 at 20:48, boB Rudis wrote:
> | So, how do
On 18 April 2016 at 20:48, boB Rudis wrote:
| 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 th
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)? Packa
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
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
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
