[R] Best Practices for submitting packages to CRAN

[Michael Friendly]

On 4/28/2011 8:43 AM, Singmann wrote:
> Dear all,
>
> I (and a colleague) have been working on our first package (for fitting a
> certain type of cognitive models:
> http://www.psychologie.uni-freiburg.de/Members/singmann/R/mptinr) for quite
> a while now and have the feeling, that it is "good to go". That is, we want
> to submit it to CRAN. However, I still have two questions before doing so
> and would appreciate any comments.
>
> 1. How often is it appropriate to submit updated versions of your package?
> Background for this question: Although we think we have tested the package
> thoroughly, there are some errors that only pop up in daily use. That is, it
> could happen that, especially shortly after the release, fixes need to be
> released rather frequently (say, every 2 weeks). On the other hand, I know
> that humans have to operate CRAN and their time is limited. Therefore, any
> update will consume their time.
You'll have to work out your own workflow for this, but a general 
practice might be to release a new version (with an incremented version 
number)  whenever you feel there are significant changes,
particularly those that are user-visible or change usage.

This assumes that your package passes R CMD check and R CMD build
without errors or warnings, with the current version of R.
If so, most of what happens on CRAN is automatic.  Otherwise
you may provoke one of the trolls under the CRAN bridge or even
a human.

You might find it easier to register the project on R-Forge and
do updates from there/

>
> 2. Is it necessary to put examples that take a considerable amount of time
> to run (>  1 hour) into a \dontrun block? Background: We have a really slow
> MCMC function. Some of the examples take ~1 hour to finish. If these
> examples are run each time the package is checked, it will significantly
> prolong the checking time. On the other hand, this check will ensure that
> all changes to the function do not corrupt it.

Yes, do use \dontrun{ ... } for stuff in examples that is inconvenient
or difficult to actually run each time during checking.  Sometimes 
people include the output from such dontrun examples as comments inside 
the example as in

\dontrun{
1+1
## 2
}

But then the responsibility is yours to make sure that the examples 
still work after updates.

>
> --
> View this message in context: http://r.789695.n4.nabble.com/Best-Practices-for-submitting-packages-to-CRAN-tp3480870p3480870.html
> Sent from the R help mailing list archive at Nabble.com.
>