[R-pkg-devel] Submission to CRAN when package needs personal data (API key)

[Dirk Eddelbuettel]

On 7 September 2018 at 09:27, Gábor Csárdi wrote:
| When are users running tests for packages at all? The tests are by default
| no even installed with the package. The only time I usually do this is when

Which some people consider to be the wrong decision by testthat.

Base R has a set of functions

   tools::testInstalledBasic
   tools::testInstalledPackage
   tools::testInstalledPackages

so that an _installed_ package can be tested.  Unless, of course, it uses
testthat.  Matt Dowle just run into this (per a question on StackOverflow).
RUnit, on the other hand, supports this.

Being able to test installed packages is useful when you change any upstream
dependency (may as author of a dependency), change a system library, change
the R version, or are simply diligent about your system.

Removing the ability to do so, or requiring a reinstallation (via a temporary
or permanent setting of another options) of the package, does not help in
that matter.

| running reverse dependency checks. In this specific case I can easily set
| ON_CRAN as well, if I want to replicate the CRAN tests. Or, maybe even better,
| I don't set it, and run the extended test suite to potentially catch more
| breakage.
| 
| > Clearly authors might want more extensive tests like the ones you mention.
| >
| > I think it would be a good thing if a standard method evolved for others
| > to ask for those tests as well.
| 
| If they don't set ON_CRAN (which they already don't),  then they get the
| extended test suite by default.

I have mentioned this a few times in the past but here is what Rcpp does in a
_fully automated manner_

   1. By default a limited number of tests are running to keep the run-time
      of 'R CMD check' short enough.

   2. Unless you define an override environment variable (which we do eg for
      Travis CI) and extended tests are running (eg in development)

   3. Or unless the package version signals a development version in which
      the environment variable gets set and extended are running.

The check for 'development' version is simple: interim version are labelled
as eg right now 0.12.18.2 having _four_ components. We infer a development
version.   Release version like 0.12.18 on CRAN only ever have three.  So we
can test and automate.  This is not perfect, but it is a step up from having
to define
 
Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | edd using debian.org