[R] Should I wrap more package examples in \dontrun{} ?

Ben Bolker bbolker at gmail.com
Wed Sep 4 00:33:12 CEST 2013


Hadley Wickham <h.wickham <at> gmail.com> writes:

> 
> >> It was my understanding that package authors are responsible for not
> >> breaking other CRAN packages without warning.  For example, before I
> >> release a new version of plyr or ggplot2, I run R CMD check on every
> >> package that depends on my package. I then let the maintainers know if
> >> something is broken - sometimes it's because I introduced a bug, and
> >> other times it's because I'm enforcing a stricter check than I did
> >> previously
> >
> > It sounds as though you're doing the right thing.  
> > Can you describe how you
> > determine the set of packages to check, and how you do your checks?  It
> > would be great if we could convince everyone to follow those steps.
> 
> I have some functions in devtools to do this:
> 
> library(ggplot2)
> revdep("ggplot2")
> 
> # Takes a _long_ time
> revdep_check("ggplot2")
> 


  There is also some infrastructure in the tools package for doing 
this task, especially tools::check_packages_in_dir .  I also reinvented
some of these wheels: see
https://github.com/lme4/lme4/tree/master/misc/pkgtests ... the main
differences between my home-grown version and the 'tools' version
is that I have some crude logic that only re-checks packages that
are more recent than the last test (re-testing from a clean
set-up is better, but as Hadley notes it's very time-consuming).

  My output looks like this:

http://htmlpreview.github.io/?https://github.com/lme4/lme4/blob
  /master/misc/pkgtests/lme4_compat_report.html

 [broken URL]


> Winston, cc'd, build some additional infrastructure on top of this, so
> that tests are run in parallel on a fast EC2 instance, and checked
> into a git repo (e.g. https://github.com/wch/ggplot2-checkresults).
> That makes it very easy to do a diff
> (https://github.com/wch/testthat-checkresults
> /commit/179219f2563330449ea2bf9aa44d70dbc96ea0e6),
> and see what packages are failing now that didn't fail in the past.
> 
> Hadley
>



More information about the R-help mailing list