cransays - Follow your R Package Journey to CRANterbury with our Dashboard!
We at Locke Data maintain a few R packages that we’ve submitted to CRAN to help increase their userbase. After running
devtools::release(), clicking in a confirmation email… what remains is waiting. Inspired by our experience, we’ve created a dashboard to help other package maintainers follow their package’s journey to CRANterbury. Read more about its making in this post!
Why create the cransays dashboard?
Sometimes, depending on the workload of CRAN volunteers, it can last a while before a package ends up on their way to CRAN. The number of submissions has increased a lot within the last few years! As per CRAN policies, “You can check that the submission was received by looking at ftp://CRAN.R-project.org/incoming/.". The content of that ftp server is divided into various subfolders, making the research of one’s package pretty tricky.
After having to do that a few days in a row for checking on one of our submissions, we decided a dashboard showing all packages and their submission stage in one go would be quite useful, so we made it happen!
How we made the cransays dashboard?
In this section you’ll discover how we create a snapshot of the CRAN incoming state, format it, and then deploy it to the interwebs every hour!
Creating a snapshot of CRAN incoming
First of all, we wrote a function
take_snapshot() to create a snapshot of the ftp server. Technically, we query the different ftp folders using
utils::read.delim(), munging strings and datetimes along the way. Our original code was adapted from an insightful repo by Edgar Ruiz at RStudio, that is a good read about the different stages of submission.
Presenting the snapshot
Then, the dashboard itself is the
data.frame returned by
take_snapshot() formatted by the
DT package. The formatting of that
datatable was improved thanks to external contributions again! Thank you, Hugo Gruson and Jim Hester!
Packaging it all together
Find the source for our dashboard here.
cransays is structured as a package, because
Packages are cool, duh!
It helps with managing dependencies thanks to DESCRIPTION.
It allowed us to rip off the benefits of
tic. We wrote the
DTcode inside a vignette –
usethis::use_vignette()for the win. Then, with the two lines below, we were able to deploy a website for the package from Travis! Every push to the master branch of our repo meant
pkgdown::build_site()is run on Travis and the result is pushed to a gh-pages branch!
# install.packages("usethis") # remotes::install_github("ropenscilabs/tic") usethis::use_pkgdown() # creates the pkgdown config file travis::use_tic() # creates boilerplate deploy code, lets you browse GitHub and Travis to create tokens.
We added a few lines to and _pkgdown.yml and travis.yml to be able to use our own
pkgdown style. Steph wrote posts about deploying docs from Travis in case you want to know more about the process but when using rOpenSci’s packages
travis, you don’t even need to think about it much.
Updating it regularly!
Steph took care of the deploy via Netlify to a subdomain of itsalocke.com, otherwise we could have used the GitHub pages hosting from the gh-pages branch. Steph also created a Zapier zap so that there’d be a Travis build triggered every hour. It means that our dashboard is updated at least every hour, which seemed lagom.
Sit back and enjoy, or improve the project?
Now, we’re able to follow our submissions using our nifty dashboard, and you can do that too! We’ve also been thinking about:
and saving the snapshots over time, very similar to what the RStudio folks did in the spring.
Stay tuned via
cransays’ issue tracker! In the meantime, happy R package development, and good luck with your CRAN submissions!