rOpenSci | rOpenSci News Digest, April 2021

rOpenSci News Digest, April 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

Are you interested in volunteering as a package reviewer for rOpenSci? We have just updated our volunteering form to make it easier to match volunteers and packages. It only takes a few minutes to fill the form. Thanks to the more than 150 people who already answered, we’re very thankful for your participation!

We have two fantastic community calls coming up! The first of them will be paired with a hands-on Social event called label-athon.

  • Set Up Your Package to Foster a Community on Thursday, 22 April 2021 16:00 UTC. rOpenSci puts ongoing effort into exploring and communicating how developers can best attract attention to their package (e.g. usage, citations, or feedback), or how to set up their repository to encourage the types of contributions they want. In this 1-hour community call, Maëlle Salmon, Hugo Gruson, and Steffi LaZerte will share tips and examples on how to do this!

  • That community call will be followed by an experimental event: a social co-working label-athon on Thursday, 29 April 2021 16:00 UTC for which registration is recommended.

  • rOpenSci’s R-universe Project on Tuesday, 25 May 2021 17:00 UTC. The R-universe platform is a new umbrella project under which rOpenSci experiments with new ideas for improving publication and discovery of research software in R. In this 1-hour community call, Jeroen Ooms will introduce the R-universe, including providing a user perspective, and share how we think this sort of tooling can help scientists publish and discover research software.

Find out about more events.

🔗 Software 📦

🔗 New packages

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

  • circle, developed by Patrick Schratz: Tools for interacting with the Circle CI API. Besides executing common tasks such as querying build logs and restarting builds, this package also helps setting up permissions to deploy from builds. It has been reviewed by Max Joseph, Sharla Gelfand.

  • dataaimsr, developed by Diego R. Barneche together with AIMS Datacentre : AIMS Data Platform API Client which provides easy access to AIMS Data Platform scientific data and information. It has been reviewed by Sam Albers, Elizabeth Stark, Laura DeCicco.

  • stantargets, developed by William Michael Landau: Bayesian data analysis usually incurs long runtimes and cumbersome custom code. A specialized pipeline toolkit for Bayesians, the stantargets R package leverages targets and cmdstanr to ease these burdens. stantargets makes it super easy to set up useful scalable Stan 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. stantargets can access all of cmdstanr’s major algorithms (MCMC, variational Bayes, and optimization) and it supports both single-fit workflows and multi-rep simulation studies. For the statistical methodology, please refer to Stan documentation (Stan Development Team 2020) https://mc-stan.org/. It has been reviewed by Krzysztof Sakrejda, Matthew T. Warkentin.

Discover more packages, read more about Software Peer Review.

🔗 New versions

The following twenty-one packages have had an update since the latest newsletter: arkdb (v0.0.11), bomrang (v0.7.4), c14bazAAR (2.1.0), DataPackageR (v0.15.8), dbhydroR (v0.2-8), elastic (v1.2.0), GSODR (v3.1.0), hydroscoper (1.4), lightr (v1.4), magick (v2.7.1), osmdata (v0.1.5), osmplotr (v0.3.3), skimr (v2.1.3), spatsoc (v0.1.16), stats19 (1.4.1), stplanr (0.8.2), tarchetypes (0.1.1), targets (0.3.1), taxadb (0.1.2), taxlist (v0.2.1), UCSCXenaTools (v1.4.3).

🔗 Software Peer Review

There are twenty recently closed and active submissions and 2 submissions on hold. Issues are at different stages:

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

🔗 On the blog

🔗 Citations

No new citations added to our database this month (browse all citations). Thanks for citing our tools!

🔗 Use cases

Two 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. 👀

Are the results of R CMD check indicating files mysteriously disappear? Could the culprit be the .Rbuildignore file? That’s always good to have in mind, as you might have not assessed all consequences of the regular expressions you added in there. And what about files that mysteriously do not disappear despite being listed in .Rbuildignore? After checking the regular expression, also check that the file is not e.g. locked (on MacOS), which is a tip reported by Eric Scott.

rOpenSci development guide does not have many requirements on coding style. But what if you are looking for guidance on the topic? Besides reading the source of packages 😉, you could check out the Tidyverse style guide by Hadley Wickham including advice on e.g. error messages.

Also coming from the tidyverse, some functions of Lionel Henry’s rlang package might be relevant when developing your R package: generate or handle a missing argument, match an argument to a character vector (with an error matching the tidyverse style guide), check a package is installed. Last but not least if you are a purrr user, rlang (MIT-licensed) has a file called compat-purrr.R with functions that allow for a similar style of programming than with purrr, minus the dependency on purrr (thanks Gábor Csárdi for this tip).

Now some workflow advice! When writing unit tests for your package, it can be very useful to use covr::report() (or covr::file_report()) to check and browse(!) your coverage progress without pushing to GitHub to as reminded by Lluís Revilla Sancho in rOpenSci semi-open slack. This good piece of advice echoes the workflow advised in the testing chapter of the book “Mastering Shiny” by Hadley Wickham (the workflow can also be applied to packages that do not use Shiny).

Do you feel like a package development “newbie”? Stefan McKinnon Høj-Edwards wrote a nice message on R-package-devel about why not to use neither “newbie” nor “luser” to describe yourself when asking a question about R package development, as it might inhibit you and others. On a more meta level, Stefan’s message is a good example of how to build a welcoming community.

🔗 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.