Dear all, Thanks a lot for your replies. These have been really helpful for solving the issue with the examples run time. I am also becoming interested in applying a similar solution for package tests. I currently run tests with RUnit. Looking at testthat, I have seen tests can be skipped with skip_on_cran, which seems to determine if tests are run on CRAN through the value of environment variable "NOT_CRAN" Can I safely assume that NOT_CRAN will be "false" on CRAN machines? Thanks a lot in advance Best wishes, Rafa
De: R-package-devel <r-package-devel-bounces at r-project.org> en nombre de Ben Bolker <bbolker at gmail.com>
Enviado: lunes, 30 de noviembre de 2020 20:59 Para: r-package-devel at r-project.org <r-package-devel at r-project.org> Asunto: Re: [R-pkg-devel] Conditional timeout for httr request when running R CMD check ******************* This email originates from outside Imperial. Do not click on links and attachments unless you recognise the sender. If you trust the sender, add them to your safe senders list https://spam.ic.ac.uk/SpamConsole/Senders.aspx to disable email stamping for this address. ******************* as pointed out to me the last time I was struggling with similar issues, if (interactive()) { ... } is another potential solution On 11/30/20 2:48 PM, Henrik Bengtsson wrote: > The problem here was regarding user facing example():s, not package tests. > > In order to keep a neat example for the user to play with, I'd > probably wrap the example code in a \donttest{} statement. Though, I > don't remember if CRAN tests with R CMD check --run-dontest, or not. > There's also \dontrun{}. > > My $.02 > > /Henrik > > On Mon, Nov 30, 2020 at 11:09 AM Jeff Newmiller > <jdnewmil at dcn.davis.ca.us> wrote: >> Don't test against a live website for most of your testing... use recorded or simulated input. If your package functional interface doesn't allow for that, then re-factor it so it does. >> >> For those tests that actually have to interact with the live website, only run them if you know you are not on CRAN. The testthat package has support for this if you don't want to roll your own. >> >> On November 30, 2020 10:45:01 AM PST, "Ayala Hernandez, Rafael" <r.ayala14 at imperial.ac.uk> wrote: >>> Dear all, >>> >>> My package openSkies includes a set of functions to retrieve >>> information from the OpenSky API. >>> >>> The examples for these functions can, on rare occassions, take >>> anomously longer times to complete than usually because of issues on >>> the API side. >>> >>> I have already included a timeout parameter to prevent endless attempts >>> to retrieve the result when, for example, the API is down for >>> maintenance. >>> >>> I have recently been asked by CRAN to reduce the execution time of each >>> example to below 5 s. In order to do this, I can set the timeout >>> parameter to something below 5s, and return NULL and a message >>> indicating the resource is not currently available. However, I think >>> this might not be the best option for examples that demonstrate >>> important functionalities to users. >>> >>> Therefore, I was wondering if there is anyway to set up the timeout >>> parameter to a different value than usual based on the condition that >>> examples are being run as part of R CMD check? >>> >>> Thanks a lot in advance >>> >>> Best wishes, >>> >>> Rafa >>> >>> [[alternative HTML version deleted]] >>> >>> ______________________________________________ >>> R-package-devel at r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-package-devel >> -- >> Sent from my phone. Please excuse my brevity. >> >> ______________________________________________ >> R-package-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-package-devel > ______________________________________________ > R-package-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel ______________________________________________ R-package-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel