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 is hiring its next Community Manager!
Come be part of making our great community even better;
Help start a new program promoting diverse leadership in open source;
Join a remote, flexible, global, friendly community and team!
More details in the job ad.
Next coworking sessions
Join us for social coworking & office hours monthly on 1st Tuesdays! Hosted by Steffi LaZerte and various community hosts. Everyone welcome. No RSVP needed. Consult our Events page to find your local time and how to join.
Our next sessions are:
Tuesday, 01 March 2022, 9 AM North American Pacific / 17:00 UTC “Changing package maintainers”, Hosted by Steffi LaZerte and Hannah Owens
- Cowork on a project of your choice;
- Take this time to ensure your packages are understandable to potential collaborators (or future maintainers);
- Or ask our community host, Hannah Owens, about her experience taking over maintenance of the rOpenSci spocc package.
Tuesday, 05 April 2022 9 AM Australian Western / 1:00 UTC “Making figures sparkle” Hosted by Steffi LaZerte and Nick Tierney
- Cowork on a project of your choice;
- Work on some figures to make them glitter;
- Or ask our community host, Nick Tierney (author of data visualization packages including rOpenSci package visdat) for some tips to make your figures sparkle!
Find out about more events.
Maëlle Salmon (Research Software Engineer with rOpenSci) and Karthik Ram (rOpenSci executive director) authored a commentary “The R Developer Community Does Have a Strong Software Engineering Culture” in the latest issue of The R Journal edited by Di Cook, as a response to the discussion paper “Software Engineering and R Programming: A Call for Research” by Melina Vidoni (who’s an Associate editor of rOpenSci Software Peer Review).
Ready for more? Two other interesting reads are the commentaries “We Need Trustworthy R Packages” by Will Landau (who maintains rOpenSci packages targets and drake), and “The R Quest: from Users to Developers” by Simon Urbanek.
The following three packages recently became a part of our software suite:
frictionless, developed by Peter Desmet together with Damiano Oldoni: Read and write Frictionless Data Packages. A Data Package (https://specs.frictionlessdata.io/data-package/) is a simple container format and standard to describe and package a collection of (tabular) data. It is typically used to publish FAIR (https://www.go-fair.org/fair-principles/) and open datasets. It is available on CRAN. It has been reviewed by Beatriz Milz, and João Martins.
rfema, developed by Dylan Turner:
rfemaallows users to access The Federal Emergency Management Agencys (FEMA) publicly available data through their API. The package provides a set of functions to easily navigate and access data from the National Flood Insurance Program along with FEMAs various disaster aid programs, including the Hazard Mitigation Grant Program, the Public Assistance Grant Program, and the Individual Assistance Grant Program. It has been reviewed by François Michonneau, and Marcus Beck.
tidytags, developed by K. Bret Staudt Willet together with Joshua M. Rosenberg: The tidytags package coordinates the simplicity of collecting tweets over time with a Twitter Archiving Google Sheet (TAGS; https://tags.hawksey.info/) and the utility of the rtweet package (https://docs.ropensci.org/rtweet/) for processing and preparing additional Twitter metadata. tidytags also introduces functions developed to facilitate systematic yet flexible analyses of data from Twitter. It has been reviewed by Lluís Revilla Sancho, and Marion Louveaux.
The following fifteen packages have had an update since the last newsletter: frictionless (
v1.0.0), av (
v0.7.0), c14bazAAR (
3.4.0), gittargets (
0.0.3), katex (
v1.4.0), nasapower (
v4.0.4), osmdata (
v0.1.9), parzer (
v0.4.1), pdftools (
v3.1.0), rfema (
v1.0.0), rgbif (
v3.7.0), riem (
v0.3.0), terrainr (
v0.6.0), tic (
v0.11.4), and tidytags (
Software Peer Review
There are twenty recently closed and active submissions and 4 submissions on hold. Issues are at different stages:
Three at ‘6/approved’:
Three at ‘5/awaiting-reviewer(s)-response’:
Five at ‘4/review(s)-in-awaiting-changes’:
Six at ‘3/reviewer(s)-assigned’:
Three at ‘1/editor-checks’:
Find out more about Software Peer Review and how to get involved.
On the blog
- A Journey to gghdr by Sayani Gupta. gghdr: An R package for graphing highest density regions in ggplot2.
A Blend of Package Build Failures by Maëlle Salmon. Some common and less common problems we saw in logs of package and pkgdown website builds.
pkgcheck now available as a GitHub action! by Mark Padgham, and Jacob Wujciak-Jens. All packages submitted for peer-review with rOpenSci are checked by our pkgcheck package. This post describes a new GitHub action which can be used to run pkgcheck. .
One use cases of our packages and resources have been reported since we sent the last newsletter.
- Calculating US Residential Segregation Indices in A Reproducible Pipeline. Reported by Boyi Guo.
Package development corner
Some useful tips for R package developers. 👀
Make the best out of your package logo
Have you designed (or commissioned) a beautiful logo for your package?
usethis::use_logo() that will enforce a specific size and save it under
man/figures/logo.png, as well as providing you with the Markdown code to insert your logo in your package repo README.
Why do this? This has two advantages:
If you have a package-level doc (i.e. a manual page for
?package-name), or create one via
usethis::use_package_doc(), roxygen2 will automatically add the logo to that doc page. Type
?usethisin your R console for an example.
If you use pkgdown BS5 templates, which is the case if your package is part of rOpenSci suite, your package logo will appear on all pages, as well as in social media cards.
Resources about testing
Some links about testing your package…
- When wondering what good tests look like (spoiler: they look obvious): Why Good Developers Write Bad Unit Tests (seen via an issue in the R packages book repo).
- When things go well in one testing context (say,
devtools::test()) but not in another one (say,
devtools::check()): a conversation around usual suspects. One prevention strategy is to read and apply the advice in testthat Test fixtures vignette.
- When having to put helper code somewhere: Helper code and files for your testthat tests.
- That interacts with a database: dittodb by Jonathan Keane and Mauricio Vargas.
- That interacts with a web resource: HTTP testing in R (or the more recent httptest2 package that is like httptest, but for httr2).
The state of continuous integration (CI) for R packages
If you adopt GitHub Actions,
Have a look at the changelog for r-lib/actions if these are the actions you use;
Do not miss the tech note “pkgcheck now available as a GitHub action!”.
Miscellaneous package building advice
See the tech note A Blend of Package Build Failures.
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.