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

From: Spencer Graves <spencer.graves_at_structuremonitoring.com>
Date: Fri, 29 Apr 2011 20:41:32 -0700

Two additions to Michael Friendly's comments:

  1. Have you considered putting your package on R-Forge (r-forge.r-project.org)? They have a facility (which has been broken for several months now but will likely be fixed again at some time in the future) to test your package more or less daily on 7 different combinations of operating system and versions of R. This has occasionally found errors that I could not replicate -- but could nevertheless fix! It also makes it easy for you to have people test a new version before you want to release it, e.g., via install.packages("fda", repos="http://R-Forge.R-project.org")' for the "fda" package.
  2. In addition to "\dontrun", you can also put tests you DO want to perform but don't want to show the user in "\dontshow". I use this latter routinely to do unit tests. There is an RUnit package, which I probably should learn to use but haven't, and there are other unit testing facilities with R that others can discuss that can help you produce "trustworthy software" (John Chambers 2008 Software for Data Analysis, Springer). Rather than learn these other facilities, I routinely program unit tests in the examples section of my help files, often using a construct like the following:

myAnswer <- myFun()

correctAnswer <- list(whatever)

\dontshow{stopifnot(}
all.equal(myAnswer, correctAnswer)
\dontshow{)}

       The code won't pass "R CMD check" until "myAnswer" and "correctAnswer" are essentially equal.

       When I find or someone reports a bug, I first program another check like this into the help file. Then I fix the bug. After that, I have confidence that if something other change introduces a problem like that, I'll know it before it reaches users other than me.

       sg

On 4/29/2011 8:12 PM, Michael Friendly wrote:
> 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.
>

-- 
Spencer Graves, PE, PhD
President and Chief Operating Officer
Structure Inspection and Monitoring, Inc.
751 Emerson Ct.
San Josť, CA 95126
ph:  408-655-4567

______________________________________________
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:55:32 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 - 05:00:34 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