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

Duncan Murdoch murdoch@dunc@n @ending from gm@il@com
Fri Sep 7 14:32:07 CEST 2018

On 07/09/2018 4:27 AM, Gábor Csárdi wrote:
> On Fri, Sep 7, 2018 at 9:01 AM Duncan Murdoch <murdoch.duncan using gmail.com> wrote:
> [...]
>> I think it's useful to think of 3 groups who might run tests:
>>    - authors
>>    - CRAN
>>    - other users of a package.
>> What Hadley was arguing for is that CRAN should identify itself to a
>> package, so that by default a package could run different tests for
>> CRAN than for other users.  I am arguing that they should run the same
>> tests by default.
> When are users running tests for packages at all?

I do sometimes, but I do agree this is a rare case.  So why does it need 
to be distinguished from CRAN?

  The tests are by default
> no even installed with the package. 

They should be in the tarball, which is what I would be starting with 
when I wanted to run the tests.

The only time I usually do this is when
> 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 think we are just getting repetitive now.  The question is whether the 
tests reported on CRAN should be the defaults or special ones.  You (and 
Hadley) think they should be a special subset.  I think they should be 
the default ones, and the author should be free to define one or more 
sets of more extensive tests to run on request.

Since CRAN is famously uncommunicative and unresponsive to suggested 
changes, I think the current state of affairs (which suits my 
preferences) will continue.  So why not make it easier to live with, by 
promoting a standard way to request special tests, rather than 
continuing to beat this dead horse?

Duncan Murdoch

More information about the R-package-devel mailing list