You’ve put together a great package that you’re proud of and you’d like to share it with the R community? Maybe even submit it to CRAN?
Before you do that, you know that a few checks are recommended… yes you do! but devtools::check() returns 7 warnings, 12 notes and 200 unclear lines so….
So you’ve come to the right place! Because we’re pleased to announce that the first version of our {checkhelper} package, your companion designed to make the process of checking your package easier, is now available on CRAN!
We’re off for a deep dive into the world of CRAN!
Let’s take a dive into {checkhelper}’s uses and related functionalities.
{checkhelper}, a companion for all R package developers
Table of Contents
The devtools::check() function is classically used during the development of a package to perform checks on various aspects such as coding errors, documentation problems, and other issues that could hamper the functionality of a package. {checkhelper} is intended to guide you through the (sometimes dense and nebulous) output of this function.
{checkhelper}](https://thinkr-open.github.io/checkhelper/) is designed to make it easier to identify and resolve problems with the “check” in your package, often caused by small oversights… it happens to everyone!
{checkhelper} contains various functions to help you solve “classic” check() problems, such as :
print_globals()returns the code containing all the global variables in your package and tells you how to save it in aglobals.Rfile.checkhelper::find_missing_tags()shows you problems with {roxygen2} tags (@returnwith no value for an exported function, documented function with no@exportor@noRdtag)- **checkhelper::check_clean_userspace()
** tells you which **hanging files** are potentially created whendevtools::check()` is run (outputs from examples, tests or vignettes of your package), and which are not cleaned up after the “check”. In particular, the ones we don’t really like are the files which remain in the user’s workspace… - checkhelper::use_data_doc()` automatically creates the documentation associated with data included in your package in .rda or .RData format.
{checkhelper} is therefore useful for all package developers, as it helps to maintain and improve the quality of their products, whether or not they are intended to be submitted to CRAN.
{checkhelper}, to jump the wall between your package and the CRAN
You may also have thought of publishing your package on the Comprehensive R Archive Network: CRAN. This is another step towards joining the ranks of the R community and also greater visibility for your work.
But it’s likely that the submission procedure will have left you a little cold. Yes, we like the CRAN submission process when we’re on the user side, because it guarantees that the package is well documented and reliable. In short, a gage of quality and trust. But when you want to go over to the other side of the mirror, preparing the submission can be a bit scary.
Luckily, {checkhelper} is here to help you with this challenge too!
{checkhelper} contains an experimental function checkhelper::check_as_cran() which uses the “check” configurations and scripts used by the CRAN for the Linux machine and which you can find here: https://github.com/r-devel/r-dev-web/tree/master/CRAN/.
This allows you to check your package locally before submitting it to CRAN, making sure that all the directives are respected, thus increasing the chances of acceptance.
Note that this experimental function, configured for Linux, is not a substitute for submission to {rhub} servers with devtools::check_rhub(), nor for testing on CRAN servers with devtools::check_win_devel(), devtools::check_win_release() and devtools::check_mac_release().
We recommend that you follow the list of tools for CRAN submission that we maintain in our GitHub repository: Preparing your package for a CRAN submission
{fusen} and {attachment}, other allies for successful checks
Have you followed {checkhelper}’s instructions and your checks aren’t going green?
Our {fusen} and {attachment} packages are here to help you develop packages and maintain them on other fronts too!
{fusen}](https://thinkr-open.github.io/fusen/) allows you to bring together the source code of your functions, their documentation and associated tests in a single Rmarkdown or Quarto file. The code in your Rmd file is distributed to folders and files ad hoc by {fusen}. No more time wasted navigating between files during development, so fewer errors, and above all, you don’t forget to write the unit tests! What’s more, development with {fusen} is even easier than before, as the latest version of {fusen} can manage all Rmd files at the same time (see our article “Inflate them all!”).
{attachment} makes it easier to manage the dependencies of your functions on other packages. And it too has recently undergone a minor upgrade to allow you to write less and less boring code while keeping a top-notch check! (see our article {attachment} v0.4.0 : Major changes and a configuration file for a better experience)
Going further with {checkhelper}
You can find {checkhelper} on CRAN and on GitHub for its development version
To read the full documentation for the {checkhelper} package, you can follow this link to the {pkgdown} site.
Other features are in the pipeline for {checkhelper}, such as the ability to produce a “code coverage” at the same time as the “check”, without running the tests twice, in order to reduce the calculation time which is sometimes very long for large packages. If you would like to take part in these developments by reporting bugs or submitting pull requests, please visit the {checkhelper} github page (https://github.com/ThinkR-open/checkhelper/).
Check out our other contributions to open-source and the R community here
