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.
The post Lessons learned from a recent R package submission appeared first on Statistical Modeling, Causal Inference, and Social Science.