I'm concerned this thread is heading the wrong way, towards techno-fixes for
imaginary problems. R package-building is already encumbered with a huge set of
complicated rules, and more instructions/rules eg for metadata would make
things worse not better.
RCMD CHECK on the 'mvbutils' package generates over 300 Notes about "no visible
binding...", which inevitably I just ignore. They arise because RCMD CHECK is
too "stupid" to understand one of my preferred coding idioms (I'm not going to
explain what-- that's beside the point). And RCMD CHECK always will be too
"stupid" to understand everything that a rich language like R might quite
reasonably cause experienced coders to do.
It should not be CRAN's business how I write my code, or even whether my code
does what it is supposed to. It might be CRAN's business to try to work out
whether my code breaks CRAN's policies, eg by causing R to crash horribly--
that's presumably what Warnings are for (but see below). And maybe there could
be circumstances where an automatic check might be "worried" enough to alert
the CRANia and require manual explanation and emails etc from a developer, but
even that seems doomed given the growing deluge of packages.
RCMD CHECK currently functions both as a "sanitizer" for CRAN, and as a
developer-tool. But the fact that the one programl does both things seems
accidental to me, and I think this dual-use is muddying the discussion. There's
a big distinction between (i) code-checks that developers themselves might or
might not find useful-- which should be left to the developer, and will vary
from person to person-- and (ii) code-checks that CRAN enforces for its own
peace-of-mind. Maybe it's convenient to have both functions in the same place,
and it'd be fine to use Notes for one and Warnings for the other, but the
different purposes should surely be kept clear.
Personally, in building over 10 packages (only 2 on CRAN), I haven't found RCMD
CHECK to be of any use, except for the code-documentation and example-running
bits. I know other people have different opinions, but that's the point:
one-size-does-not-fit-all when it comes to coding tools.
And wrto the Warnings themselves: I feel compelled to point out that it's
logically impossible to fully check whether R code will do bad things. One has
to wonder at what point adding new checks becomes futile or counterproductive.
There must be over 2000 people who have written CRAN packages by now; every
extra check and non-back-compatible additional requirement runs the risk of
generating false-negatives and incurring many extra person-hours to "fix"
non-problems. Plus someone needs to document and explain the check (adding to
the rule mountain), plus there is the time spent in discussions like this..!
Mark
Mark Bravington
CSIRO CMIS
Marine Lab
Hobart
Australia
________________________________________
From: r-devel-boun...@r-project.org [r-devel-boun...@r-project.org] On Behalf
Of Hadley Wickham [had...@rice.edu]
Sent: 30 March 2012 07:42
To: William Dunlap
Cc: r-de...@stat.math.ethz.ch; Spencer Graves
Subject: Re: [Rd] CRAN policies
> Most of that stuff is already in codetools, at least when it is checking
> functions
> with checkUsage(). E.g., arguments of ~ are not checked. The expr argument
> to with() will not be checked if you add skipWith=FALSE to the call to
> checkUsage.
>
> > library(codetools)
>
> > checkUsage(function(dataFrame) with(dataFrame, {Num/Den ; Resp ~ Pred}))
> <anonymous>: no visible binding for global variable 'Num' (:1)
> <anonymous>: no visible binding for global variable 'Den' (:1)
>
> > checkUsage(function(dataFrame) with(dataFrame, {Num/Den ; Resp ~ Pred}),
> skipWith=TRUE)
>
> > checkUsage(function(dataFrame) with(DataFrame, {Num/Den ; Resp ~ Pred}),
> skipWith=TRUE)
> <anonymous>: no visible binding for global variable 'DataFrame'
>
> The only part that I don't see is the mechanism to add code-walker functions
> to
> the environment in codetools that has the standard list of them for functions
> with
> nonstandard evaluation:
> > objects(codetools:::collectUsageHandlers, all=TRUE)
> [1] "$" "$<-" ".Internal"
> [4] "::" ":::" "@"
> [7] "@<-" "{" "~"
> [10] "<-" "<<-" "="
> [13] "assign" "binomial" "bquote"
> [16] "data" "detach" "expression"
> [19] "for" "function" "Gamma"
> [22] "gaussian" "if" "library"
> [25] "local" "poisson" "quasi"
> [28] "quasibinomial" "quasipoisson" "quote"
> [31] "Quote" "require" "substitute"
> [34] "with"
It seems like we really need a standard way to add metadata to functions:
attr(with, "special_args") <- "expr"
attr(lm, "special_args") <- c("formula", "weights", "subset")
This would be useful because it could automatically contribute to the
documentation.
Similarly,
attr(my.new.method, "s3method") <- c("my.new", "method")
could be useful.
Hadley
--
Assistant Professor / Dobelman Family Junior Chair
Department of Statistics / Rice University
http://had.co.nz/
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
