58

Actual question

How do I avoid Rd file name conflicts when

  1. a S4 generic and its method(s) are not necessarily all defined in the same package (package containing (some of) the custom method(s) depends on the package containing the generic) and
  2. using roxygenize() from package roxygen2 to generate the actual Rd files?

I'm not sure if this is a roxygen2 problem or a common problem when the generic and its method(s) are scattered across packages (which IMHO in general definitely is a realistic use-case scenario if you follow a modular programming style).

What's the recommended way to handle these situations?

Illustration

In package pkga

Suppose in package pkga you defined a generic method foo and that you've provided the respective roxygen code that roxygenize() picks up to generate the Rd file:

#' Test function
#' 
#' Test function.
#' 
#' @param ... Further arguments.
#' @author Janko Thyson \email{janko.thyson@@rappster.de}
#' @example inst/examples/foo.R
#' @docType methods
#' @rdname foo-methods
#' @export

setGeneric(
    name="foo",
    signature=c("x"),
    def=function(
         x,  
        ...
    ) {
    standardGeneric("xFoo")       
    }
)

When roxygenizing() your package, a file called foo-methods.Rd is created in the man subdirectory that serves as the reference Rd file for all methods that might be created for this generic method. So far so good. If all of the methods for this generic are also part of your package, everything's good. For example, this roxygen code would make sure that documentation is added to foo-methods.Rd for the ANY-method of foo:

#' @param x \code{ANY}.
#' @return \code{TRUE}.
#' @rdname foo-methods
#' @aliases foo,ANY-method
#' @export

setMethod(
    f="foo", 
    signature=signature(x="ANY"), 
    definition=cmpfun(function(
        x,
        ...
    ) {
    return(TRUE)
    }, options=list(suppressAll=TRUE))
)

However, if package pkga provides the generic for foo and you decide in some other package (say pkgb) to add a foo-method for x being of class character, then R CMD check will tell you that there is a name clash with respect to Rd file names and/or aliases (as there already exists a Rd file foo-methods.Rd in pkga):

In package pkgb

#' @param x \code{character}.
#' @return \code{character}.
#' @rdname foo-methods
#' @aliases foo,character-method
#' @export

setMethod(
    f="foo", 
    signature=signature(x="character"), 
    definition=cmpfun(function(
        x,
        ...
    ) {
    return(x)
    }, options=list(suppressAll=TRUE))
)

To be more precise, this is the error that's thrown/written to file 00install.out

Error : Q:/pkgb/man/foo-methods.Rd: Sections \title, and \name must exist and be unique in Rd files
ERROR: installing Rd objects failed for package 'pkgb'

Due dilligence

I tried to change the values for @rdname and @aliases to foo_pkgb* (instead of foo*), but \title and \name still are set to foo when roxygenizing and thus the error remains. Any ideas besides manually editing the Rd files generated by roxygenize()?


EDIT 2012-12-01

In light of starting the bounty, the actual question might get a slightly broader flavor:

How can we implement some sort of an "inter-package" check with respect to Rd files and/or how can we consolidate S4 method help files scattered across packages into one single Rd file in order to present a single source of reference to the end-user?

4

2 回答 2

4

基本问题确实是“roxygenize”-only。这就是为什么我从来没有看到过这个问题。

虽然包开发的 roxygenizing 方法有充分的理由,但我仍然看到一个很好的理由不去那里:

请求减少极端的氧化作用

生成的帮助页面往往看起来非常无聊,不仅是自动生成的 *.Rd 文件,还有渲染的结果。例如

  1. 示例通常很少,不包含注释,通常格式不正确(使用空格、/换行/..)
  2. 数学问题很少通过 \eqn{} 或 \deqn{} 来解释
  3. \describe{ .. } 和类似的高级格式很少使用

这是为什么?因为

1)阅读和编辑 roxygen 评论比在 ESS 或 Rstudio 或(其他内置 *.Rd 支持的 IDE)中阅读和编辑 *.Rd 文件更“麻烦”或至少在视觉上没有回报

2)如果您使用该文档

是在你的包构建/检查结束时自动生成的东西

您通常倾向于不将写得好的 R 文档视为重要的东西(而是您的 R 代码,所有文档都只是评论:-)

所有这一切的结果:人们更喜欢在小插曲甚至博客、github gists、youtube 视频或...中编写有关其功能的文档,这些文档在创作时非常好,但与代码和绑定几乎无关变得过时和枯萎(因此,通过谷歌搜索误导你的用户)--> roxygen 将代码和文档放在同一个地方的最初动机完全被打败了。

我喜欢 roxygen 并在创建新函数时广泛使用它……只要我的函数不在包中或未导出,我就会保留并维护它。一旦我决定导出它,我会运行一次(相当于 ESS 的)roxygenize() 然后承担维护格式良好的 *.Rd 文件的额外负担,包含自己的注释(对于我作为作者) ,有很多很好的例子,有自己的版本控制(git / svn / ...)历史等。

于 2013-02-02T15:05:58.953 回答
0

我设法为 S4 方法生成 NAMESPACE 和 *.Rd 文件,用于在我的另一个包中定义的泛型。

我采取了以下步骤:

  1. 手动创建 NAMESPACE 作为已知 roxygen2 错误的解决方法。

    手写一个 NAMESPACE 一点也不难!

    在 RStudio 中关闭 roxygen2 生成的 NAMESPACE:

    Build > more > Configure build tools > configure roxygen > do not use roxygen2 to generate NAMESPACE.
    
  2. 导入包含泛型的包并使用 exportMethods 导出 S4 方法

  3. 为每个 S4 方法编写单独的 roxygen2 文档。不要合并 roxygen2 文档(就像我通常对相同泛型的不同方法所做的那样)。

  4. 将显式 roxygen 标签 @title 和 @description 添加到 S4 方法的 roxygen 文档中。显式编写@description,即使它的值与@title 相同。

这使它对我有用。

于 2015-12-24T12:12:26.733 回答