October 22, 2021 From rOpenSci (https://ropensci.org/blog/2021/10/22/ropensci-news-digest-october-2021/). Except where otherwise noted, content on this site is licensed under the CC-BY license.
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!
A fantastic community call is coming up on Tuesday, 26 October 2021 18:00 UTC: Expanding Software Peer Review: Statistical Package Standards at rOpenSci!
This 1-hour community call will address the bigger picture of how our community-informed development of standards for statistical packages meets a critical need of stakeholders. Noam Ross (EcoHealth Alliance and rOpenSci Software Review Lead) will catch everyone up on the project. Rebecca Killick (Lancaster University and rOpenSci Statistical Software Peer Review advisory committee) will offer insights into standardisation and the potential role our program might play in the future of statistical software and open source software in general. Juliane Manitz (EMD Serono and R Validation Hub) will offer a perspective on the use of open source software in regulated environments. Christoph Sax (cynkra) will share his experience as the first person to submit a package, tsbox, for review and aligning his software with our standards.
Follow the community call page link for practical information. Everyone is welcome, no RSVP needed!
Join us for monthly coworking Tuesday, November 2nd at 16:00 UTC! No RSVP needed. In addition to the usual quiet and noisy rooms (for Q&A and meeting peers), Mark Pagham, co-Lead of our Statistical Software Peer Review project, will be there to help folks check their own package with our new automated checking system.
The conference is free with registration. Conference website.
Find out about more events. You can subscribe to rOpenSci-lead events via our ICS calendar (copy the link, add it to your calendar service e.g. Thunderbird or Google Calendar). Please note that if you use Google Calendar you have to check synchronization is turned on; furthermore, synchronization might be delayed.
We are excited to welcome Emily Riederer, Adam Sparks, and Jeff Hollister to our team of Associate Editors for rOpenSci Software Peer Review. They join Laura DeCicco, Julia Gustavsen, Anna Krystalli, Mauro Lepore, Karthik Ram, Noam Ross, Maëlle Salmon, and Melina Vidoni. Find out more about the three new editors in our introduction blog post.
The following package recently became a part of our software suite:
The following nine packages have had an update since the latest newsletter: gert (
v1.4.1), arkdb (
v0.0.14), GSODR (
v3.1.4), lingtypology (
v1.1.6), osmdata (
v0.1.7), rglobi (
v0.2.26), ruODK (
v1.3.0), stplanr (
v0.8.4), USAboundariesData (
There are fourteen recently closed and active submissions and 4 submissions on hold. Issues are at different stages:
One at ‘6/approved’:
Four at ‘4/review(s)-in-awaiting-changes’:
Three at ‘3/reviewer(s)-assigned’:
Three at ‘2/seeking-reviewer(s)':
One at ‘1/editor-checks’:
Find out more about Software Peer Review and how to get involved.
Three use cases of our packages and resources have been reported since we sent the last newsletter.
Using jsonvalidate to validate the
packages.json file from your personal universe. Reported by Hugo Gruson.
Creating historical Congressional maps with USABoundaries. Reported by Andrew Heiss.
Predizendo volume de eucalipto com tidymodels, XGBoost e targets. Reported by Theilon Macêdo.
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
[email protected] to get your call for maintainer featured in the next newsletter.
Some useful tips for R package developers. 👀
Do you have a fantastic idea and plan for a package, but no name for it yet? We have some tips on this topic in our dev guide!
We strongly recommend short, descriptive names in lower case. If your package deals with one or more commercial services, please make sure the name does not violate branding guidelines. You can check if your package name is available, informative and not offensive by using the
available package. In particular, do not choose a package name that’s already used on CRAN or Bioconductor.
A more unique package name might be easier to track (for you and us to assess package use) and search (for users to find it and to find answers to their questions). Obviously a too unique package name might make the package less discoverable (e.g. it might be an argument for naming your package geojson). Also note that removing random letter e.g. vowels from a common word to create a package name might make it less easy to remember!
Find other interesting aspects of naming your package in this blog post by Nick Tierney, and in case you change your mind, find out how to rename your package in this other blog post of Nick’s.
The testthat package has been supporting snapshot tests that “record expected output in a separate human-readable file instead of using code to describe what the expected output looks like.” since its version 3.0.0. Their implementation is now stable. Note that they are skipped by default on CRAN.
Now what about input files for tests?
Maybe you can create fake ones on the fly (and delete them).
Or you can store them under
tests/testthat and use
testthat::test_path() when using them, to get a file path that “both interactively and during tests”.
So to use
tests/testthat/examples/thing you’d write
Note that the vcr package for HTTP testing has a similar function you can use to locate cassettes, vcr_test_path().
How to enforce a style guide for your package, without too much human effort? Two suggestions:
Having a GitHub Action workflow that allows you to call styler via typing
/style in a PR comment (or amend the logic to have it work via applying a label to the PR). Or apply this idea to another continuous integration service! If for any reason your style differs from styler’s default, follow one of styler articles for developers and tweak the workflow. Example, corresponding style guide package.
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.