[Rd] CRAN policies

Fri Mar 30 21:03:09 CEST 2012

On Fri, Mar 30, 2012 at 11:41 AM, Kevin Wright <kw.stat at gmail.com> wrote:
> I'll echo Mark's concerns.  R _used_ to be a language for "turning ideas
> into software quickly".  Now it is more like "prototyping ideas in software
> quickly", and then spend a substantial amount of time trying to follow
> administrative rules to package the code.

..if you want to submit to CRAN.  There are practically zero if you
host on your own website.  Of course developers are free to do
whatever they want and R core does not get to tell them what/how to do
it.  R core does get a say when you ask them to host your source and
build your package binaries.

> Quality has its costs.

So does using CRAN.  If it is not the best solution for your problem,
use something else.  Hadley uses github from development ggplot2, and
with the dev_tools package, it is relatively easy for users to install
the source ggplot2 code.  Something like that might be appropriate for
code/packages wehre you just want to 'turn ideas into software
quickly'.  There is an extra step required for users to use it, but
that makes sense because it weeds out inept users from using code with
less quality control.

>
> Many of the code checks I find quite useful, but the "no visible binding"
> one generates lots of nuisance notes for me.  I must have a similar coding
> style to Mark.
>
> Kevin
>
>
> On Thu, Mar 29, 2012 at 8:29 PM, <Mark.Bravington at csiro.au> wrote:
>
>> 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-bounces at r-project.org [r-devel-bounces at r-project.org] On
>> Behalf Of Hadley Wickham [hadley at rice.edu]
>> Sent: 30 March 2012 07:42
>> To: William Dunlap
>> Cc: r-devel at 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 at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
>
>
> --
> Kevin Wright
>
>        [[alternative HTML version deleted]]
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

-- 
Joshua Wiley
Ph.D. Student, Health Psychology
Programmer Analyst II, Statistical Consulting Group
University of California, Los Angeles
https://joshuawiley.com/