On 07/09/2018 4:27 AM, Gábor Csárdi wrote:
On Fri, Sep 7, 2018 at 9:01 AM Duncan Murdoch <murdoch.dun...@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
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
