[R-pkg-devel] need some help to understand package build workflow

Duncan Murdoch murdoch.duncan at gmail.com
Sat Aug 1 03:57:43 CEST 2015


On 31/07/2015 6:14 PM, Kevin Ushey wrote:
> I'm not sure if that's correct -- from what I see, in the generated Rd
> documentation:
> 
> - The 'usage' is drawn from the S4 generic,
> - The 'arguments' are drawn from the function.
> 
> I think R CMD check is correctly warning about that.

I agree the warning is correct.

I'm not so sure it's actually a Roxygen2 bug, but I think it's that, or
a missing feature.  The user documented an argument that doesn't exist,
because the function is defined twice.  Since Roxygen uses position in
the file to match docs to functions, it could have complained that the
argument docs were in the wrong place (before the inactive definition),
or it could have complained that they were inconsistent with the
expected arg list.

Duncan


> 
> On Fri, Jul 31, 2015 at 2:56 PM, Hadley Wickham <h.wickham at gmail.com> wrote:
>>>> It seems arguable that this is actually a roxygen bug - the function
>>>> that's actually exported from the package does not have a type
>>>> argument.
>>>
>>> The package fails R CMD check because of a bad .Rd file.  If a user had
>>> written that file, it would be user error, but roxygen2 wrote it, so I'd
>>> say it's pretty clearly a roxygen2 bug.
>>
>> It would really help me if you'd explain a little bit more. I think
>> the essential problem is that the package has two definitions of f:
>>
>> f <- function(x, y) {}
>> setGeneric(f, function(x) {})
>>
>> Roxygen uses the second definition (because it's the last defined),
>> and expects the function to have one argument. R CMD check clearly
>> excepts it two have two arguments. It's not obvious to me which is
>> correct.
>>
>> Hadley
>>
>> --
>> http://had.co.nz/



More information about the R-package-devel mailing list