rOpenSci | rOpenSci News Digest, September 2021

rOpenSci News Digest, September 2021

Dear rOpenSci friends, it’s time for our monthly news roundup!

You can read this post on our blog. Now let’s dive into the activity at and around rOpenSci!

🔗 rOpenSci HQ

A first package was submitted to rOpenSci Statistical Software Peer Review, two months after its opening: the tsbox package by Christoph Sax. We are very excited, and thankful for the opportunity to hone our new software review tooling!

We’ve made it easier to browse our website by adding some basic search from the navbar. The search isn’t on the full content, but on page titles and descriptions. We hope it’ll help you find what you’re after! Other ways to find an rOpenSci related thing you vaguely remember is by asking us, searching through our website source or using your favourite search engine.

Our next Social Coworking and Office Hours is Tuesday, October 5th, 9 AM Australian Western / 1:00 UTC, and hosted by Nicholas Tierney. Find out about more events.

🔗 Software 📦

🔗 New packages

The following three packages recently became a part of our software suite:

  • allodb, developed by Erika Gonzalez-Akre together with Camille Piponiot, Mauro Lepore, Kristina Anderson-Teixeira: Tool to standardize and simplify the tree biomass estimation process across globally distributed extratropical forests. It has been reviewed by Jeffrey Hanson, Jonas Stillhard.

  • jagstargets, developed by William Michael Landau: Bayesian data analysis usually incurs long runtimes and cumbersome custom code. A pipeline toolkit tailored to Bayesian statisticians, the jagstargets R package is leverages targets and R2jags to ease this burden. jagstargets makes it super easy to set up scalable JAGS pipelines that automatically parallelize the computation and skip expensive steps when the results are already up to date. Minimal custom code is required, and there is no need to manually configure branching, so usage is much easier than targets alone. For the underlying methodology, please refer to the documentation of targets doi:10.21105/joss.02959 and JAGS (Plummer 2003) https://www.r-project.org/conferences/DSC-2003/Proceedings/Plummer.pdf. It has been reviewed by David Lawrence Miller, Ernest Guevarra.

  • slopes, developed by Robin Lovelace together with Rosa Félix, Joey Talbot: Functions and example data to support research into the slope (also known as longitudinal gradient or steepness) of linear geographic entities such as roads doi:10.1038/s41597-019-0147-x and rivers doi:10.1016/j.jhydrol.2018.06.066. The package was initially developed to calculate the steepness of street segments but can be used to calculate steepness of any linear feature that can be represented as LINESTRING geometries in the sf class system. The package takes two main types of input data for slope calculation: vector geographic objects representing linear features, and raster geographic objects with elevation values (which can be downloaded using functionality in the package) representing a continuous terrain surface. Where no raster object is provided the package attempts to download elevation data using the ceramic package. It has been reviewed by Dan Olner, Andy Teucher.

Discover more packages, read more about Software Peer Review.

🔗 New versions

The following fifteen packages have had an update since the latest newsletter: gert (v1.4.0), pkgstats (v0.0.1), beastier (v2.4.8), c14bazAAR (3.1.0), DataSpaceR (v0.7.5), drake (7.13.3), europepmc (v0.4.1), NLMR (v0.6), nlrx (v0.4.3), qualtRics (v3.1.5), rebird (v1.3.0), rfishbase (slb-21.08), tarchetypes (0.3.1), targets (0.8.0), tidyhydat (0.5.4).

🔗 Software Peer Review

There are fifteen recently closed and active submissions and 5 submissions on hold. Issues are at different stages:

Find out more about Software Peer Review and Statistical Software Peer Review, including how to get involved.

🔗 On the blog

  • Creando Tu R-universe by Yanina Bellini Saibene. En este post te explico como crear tu r-universe, a partir de la experiencia de crear el mio.

  • The Story Behind rspatialdata by Dilinie Seimon, Varsha Ujjinni Vijay Kumar. rspatialdata: tutorials for working with spatial data using R, featuring many rOpenSci packages.

Screenshot of rspatialdata homepage featuring multicoloured tiles each outlining a different type of spatial data

🔗 Tech Notes

🔗 Use cases

Three use cases of our packages and resources have been reported since we sent the last newsletter.

Explore other use cases and report your own!

🔗 Call for maintainers

There’s no open call for new maintainers at this point but you can refer to our contributing guide for finding ways to get involved! As the maintainer of an rOpenSci package, feel free to contact us on Slack or email info@ropensci.org to get your call for maintainer featured in the next newsletter.

🔗 Package development corner

Some useful tips for R package developers. 👀

Short anti-struggle list:

How to test code run by callr, while having tests contribute to code coverage? covr modifies the code through injecting tracing symbols and running as its own temporary and definitely self-contained process. Any processes external to this, which includes anything via callr, cannot be traced. This is an entirely standard condition of any code tracing algorithm. A good tip is to ensure everything inside a callr call is bundled as a simple function that can be tested in tests without the callr wrapper.

Another challenge for testing might be interactive behavior. For Shiny apps you might look into shinytest, for anything happening in the browser you might enjoy chromote or crrri. You can also resort to mocking. For code that’s supposed to be only run in interactive sessions, you might use rlang functions in particular the rlang::is_interactive() in code and tests. You can look at the targets testing suite for external processes and usethis manual tests.

Now about real testers, i.e. the users! 😉 To help them use your package optimally, you have to write a nice interface, good docs (including system requirements), informative error messages, etc. Have you also considered adding some sort of sitrep (situation report) function? The devtools package has devtools::dev_sitrep() e.g. reports on the package development situation, with clear hints given if something is not quite right. The usethis package has usethis::git_sitrep() (using the gert package under the hood!), blogdown has blogdown::check_site(). Good candidates for checks are common pain points, so finding them might require some sort of external perspective on your package.

🔗 Last words

Thanks for reading! If you want to get involved with rOpenSci, check out our Contributing Guide that can help direct you to the right place, whether you want to make code contributions, non-code contributions, or contribute in other ways like sharing use cases.

If you haven’t subscribed to our newsletter yet, you can do so via a form. Until it’s time for our next newsletter, you can keep in touch with us via our website and Twitter account.