[R-pkg-devel] How to reduce examples in a package that takes more than 5 seconds to run?

Duncan Murdoch murdoch@dunc@n @end|ng |rom gm@||@com
Wed Dec 28 14:09:32 CET 2022


On 28/12/2022 7:06 a.m., Daniel Kelley wrote:
>  > I've been reminded today why this is such a bad idea.  I'm preparing an
> update of the rgl package.  As I attempt to be a good citizen, I'm doing
> comparison checks of all of the 300 packages that use it, to see if my
> updates break anything.
> 
> Hi Duncan, I'm wondering whether you are checking against CRAN sources 
> or github/gitlab/etc sources.

CRAN sources only.  Unreleased packages may have lots of errors in them, 
and it's up to their authors to test them.  Users shouldn't rely on 
those packages, but they might rely on CRAN packages, and I don't want 
to cause extra headaches for them.
> I ask because the scheme I use in my packages is that I have lots of 
> tests that only get done if a certain local file (or directory) is 
> present.  Those files/directories are listed in .Rbuildignore, so the 
> CRAN tests skip those tests.  Some of these files/directories are stored 
> in the same github repo as the package code, and some are not.  The 
> latter are because the datasets are huge, or because they are private 
> data sent to me by users to test new features.  (Often users share data 
> for testing, as I develop new code. They need to keep the data private 
> until they publish papers and theses.)
> 
> I know rgl does not depend on oce, so my question is not exactly 
> pertinent to you, but I would appreciate it if you could comment on 
> whether what I am doing seems to be useful.  To be honest, I am a bit 
> lost in how folks are supposed to handle slow tests; I'd not be happy to 
> report how many times I've done web searches to find out just what 
> \dontrun and \donttest do, and when I should use them or should do 
> something else.
> 

Your method sounds good.  You choose to run your tests, you don't force 
anyone else to run them.

Duncan Murdoch



More information about the R-package-devel mailing list