Site icon R-bloggers

rOpenSci News Digest, September 2021

[This article was first published on rOpenSci - open tools for open science, and kindly contributed to R-bloggers]. (You can report issue about the content on this page here)
Want to share your content on R-bloggers? click here if you have a blog, or here if you don't.
< !-- Before sending DELETE THE INDEX_CACHE and re-knit! -->

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

< !-- blabla -->

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:

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

< !-- Do not forget to rebase your branch! -->

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

To leave a comment for the author, please follow the link and comment on their blog: rOpenSci - open tools for open science.

R-bloggers.com offers daily e-mail updates about R news and tutorials about learning R and many other topics. Click here if you're looking to post or find an R/data-science job.
Want to share your content on R-bloggers? click here if you have a blog, or here if you don't.