All posts (Page 61 of 120)
Software is maintained by people. While software can in theory live on indefinitely, to do so requires people. People change jobs, move locations, retire, and unfortunately die sometimes. When a software maintainer can no longer maintain a package, what happens to the software?
Because of the fragility of people in software, in an ideal world a piece of software should have as many maintainers as possible. Increasing maintainers increases the so-called bus factor. A lower number of maintainers means fewer people have to get hit by a bus to then have no maintainers.
...As part of our continuous effort to improve rOpenSci infrastructure, we are rolling out a new service to automatically build and host documentation for all rOpenSci packages.
The webpages are generated using the popular pkgdown system with our rOpenSci template, and get automatically published on https://docs.ropensci.org/. Some examples:
- https://docs.ropensci.org/drake/
- https://docs.ropensci.org/magick/
- https://docs.ropensci.org/writexl/
- https://docs.ropensci.org/stplanr/
- https://docs.ropensci.org/osmdata/
- https://docs.ropensci.org/visdat/
- https://docs.ropensci.org/tesseract/
We intend this to become the central place to find documentation for rOpenSci packages. We are still rolling this out so not all packages are there yet, but the majority is online now.
...We’ve been following rOpenSci’s work for a long time, and we use several packages on a daily basis for our scientific projects, especially taxize to clean species names, rredlist to extract species IUCN statuses or [treeio](many probs with this post) to work with phylogenetic trees. rOpensci is a perfect incarnation of a vibrant and diverse community where people learn and develop new ideas, especially regarding scientific packages. We’ve also noticed how much the thorough review process improves the quality of the packages that join the rOpenSci ecosystem. And while we were admiring the dynamics of rOpenSci community, we started to wonder how we could contribute to this ecosystem. And this is how we started our quest to find a project that could fit rOpenSci goals while at the same time teach us new skills....
🔗
Introduction
ramlegacy is a new R package to download, cache and read in all the different versions of the RAM Legacy Stock Assessment Database, a public database containing stock assessment results of commercially exploited marine populations from around the world. The package accomplishes all this by:
- Providing a function
download_ramlegacy(), to download all the available versions of the RAM Database and cache them on the user’s computer in a location provided by the rappdirs package. This way once a version has been downloaded it doesn’t need to be re-downloaded for subsequent analysis. - Supporting reading in specified tables or all tables from a cached version of the database through the function
load_ramlegacy() - Providing a function
ram_dir()to view the path of the rappdirs location where the downloaded database was cached.
The primary motivation behind developing the caching behavior of the package was to save the user time and effort spent in re-downloading different versions of the database as part of any future analysis.
...We strive for high quality in our suite of packages, in practice via a system of software peer review, and via packaging guidelines that keep growing. There is therefore a risk of increasing the workload of package authors, who already have a lot on their plate. To avoid that, when explaining how to do things in our dev guide, we recommend existing automated tools to authors.
Inspired by the usethis package, we’ve started work on our specific helpers for rOpenSci package authors, rodev. In this note, we’ll present some of the helpers it contains at the moment, and ask for your feedback as an rOpenSci package author.
...
