Site icon R-bloggers

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

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

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

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

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.