[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