Re: [R] Best Practices for submitting packages to CRAN

From: Michael Friendly <friendly_at_yorku.ca>
Date: Fri, 29 Apr 2011 23:12:36 -0400

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.
>



R-help_at_r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code. Received on Sat 30 Apr 2011 - 03:17:40 GMT

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Sat 30 Apr 2011 - 04:00:37 GMT.

Mailing list information is available at https://stat.ethz.ch/mailman/listinfo/r-help. Please read the posting guide before posting to the list.

list of date sections of archive