Lessons learned from a recent R package submission

Posted on by

R has zillions of packages, and people are submitting new ones each day. The volunteers who keep R going are doing an incredibly useful service to the profession, and they’re busy.

A colleague sends in some suugestions based on a recent experience with a package update:

1. Always use the R dev version to write a package. Not the current stable release. The R people use the R dev version to check your package anyway. If you don’t use the R dev version, there is chance that your package won’t pass the check. In my own experience, every time R has a major change, it tends to have new standards and find new errors in your package with these new standards. So better use the dev version to find out the potential errors in advance.

2. After submission, write an email to claim it. I used to submit the package to the CRAN without writing an email. This was standard operating procedure, but it has changed. Writing an email to claim about the submission is now a requirement. There is a good reason. The R team is afraid that the package was not submitted by a legal developer. So there is a security issue involved here. Write an email to remind them that you submit a package, not a virus.

3. The R people are busy. The number of R packages submitted to CRAN is growing exponentially. So the R people’s working loads are heavy. We should understand their situation and try to work with them to solve the package issues, when problems come up.

The first two lessons are the most important. If you have done the first two, I believe you won’t need the third one.

I’ve never actually written an R package myself—my last experience with this sort of thing was several years ago, using dyn.load and dyn.load2 in S—but I’ve used many R packages and I’ve contributed to several widely-used R packages. So I really appreciate the effort put in by the central R people, and I’m posting this note as a way to make their lives easier and also help the people who are writing and updating R packages.

8 thoughts on “Lessons learned from a recent R package submission”

  2. I sort of disagree on 1) based on the dozen or so packages I have (co-)authored. I develop on Linux, and ‘the CRAN entry test’ in Vienna also runs its ‘R CMD check’ tests on Linux. There have been occassional issues with compiled code as CRAN uses the newest compiler versions (as present in Debian’s “testing” flavour”) — but I rarely have a need for ‘R-devel’: the current stable release is almost always good enough.

    A fourth point worth making, particularly for those of us without a Windows machine nearby: use win-builder.r-project.org, and I wish there was the same for OS X. But as you note, CRAN and its volunteers are already under some strain.

  3. Based on the second point, I wonder how recent the experience of your colleague was. :)

    The “Writing R Extensions” manual requested for ages that an e-mail be send to the CRAN maintainers whenever a package is submitted. This request (which in more recent times might be enforced), goes back at least to R 2.0.x:
    From https://svn.r-project.org/R/branches/R-2-0-patches/doc/manual/R-exts.texi
    When all the testing is done, upload the @file{.tar.gz} file to

    @smallexample
    @url{ftp://ftp.ci.tuwien.ac.at/incoming}
    @end smallexample

    @noindent
    and send a message to @url{cran@@r-project.org} about it. The
    @acronym{CRAN} maintainers will run these tests before putting a
    submission in the main archive.

    BTW, if one uses R-Forge (https://r-forge.r-project.org/) for package development, submission to CRAN (including e-mail) is pretty much automated.

    • Berwin:

      I’m sure you’re right. It’s just hard sometimes to keep track of all the rules, especially if you’ve already established a pattern of submitting and updating packages.

  4. I undertand why one won’t leave MATLAB (though I would still think has its advantages) but stata … sounds kind of amateur software … to me but maybe I just don’t know about …

    • Yes, you just don’t know about.
      (Why do you picture Stata as an amateur piece of software? What does make you think so?)

Comments are closed.