58

実際の質問

Rdファイル名の競合を回避するにはどうすればよいですか?

  1. S4ジェネリックとそのメソッドは必ずしもすべて同じパッケージで定義されているわけではありません(カスタムメソッド(の一部)を含むパッケージはジェネリックを含むパッケージに依存します
  2. roxygenize()パッケージroxygen2から実際のRdファイルを生成するために使用しますか?

ジェネリックとそのメソッドがパッケージ全体に散在している場合、これがroxygen2問題なのか一般的な問題なのかはわかりません(モジュラープログラミングスタイルに従う場合、IMHOは一般的に現実的なユースケースシナリオです)。

これらの状況を処理するための推奨される方法は何ですか?

パッケージ内pkga

パッケージpkgaでジェネリックメソッドを定義し、Rdファイルを生成するためにfoo取得するそれぞれのroxygenコードを提供したとします。roxygenize()

#' 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")       
    }
)

roxygenizing()パッケージを作成すると、このジェネリックメソッド用に作成される可能性のあるすべてのメソッドの参照Rdファイルとして機能するファイルがサブディレクトリに作成foo-methods.Rdされます。manここまでは順調ですね。このジェネリックのすべてのメソッドもパッケージの一部である場合、すべてが良好です。たとえば、このroxygenコードは、次foo-methods.RdANY-methodのドキュメントが追加されていることを確認し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))
)

ただし、パッケージpkgaがのジェネリックを提供し、foo他のパッケージ(たとえば)でクラスであるための-メソッドpkgbを追加することを決定した場合、Rdファイル名および/またはエイリアス( )にRdファイルがすでに存在します:fooxcharacterR CMD checkfoo-methods.Rdpkga

パッケージ内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))
)

より正確には、これはファイルにスロー/書き込まれるエラーです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'

デューデリジェンス

(の代わりに)との値を変更しようとしましたが@rdname、roxygenizing時に設定されているため、エラーが残ります。によって生成されたRdファイルを手動で編集する以外のアイデアはありますか?@aliasesfoo_pkgb*foo*\title\namefooroxygenize()


2012年12月1日編集

バウンティを開始することに照らして、実際の質問は少し広い味を得るかもしれません:

Rdファイルに関してある種の「パッケージ間」チェックを実装するにはどうすればよいですか。また、パッケージ全体に散在するS4メソッドヘルプファイルを1つのRdファイルに統合して、最後に単一の参照ソースを提示するにはどうすればよいですか。 -ユーザー?

4

2 に答える 2

4

基本的な質問は確かに「roxygenize」のみです。そのため、私は問題を見たことがありませんでした。

パッケージ開発の roxygenizing アプローチには正当な理由がありますが、そこに行かない非常に正当な理由がまだあります。

極端な酸素化をはるかに少なくするための嘆願

結果のヘルプ ページは、自動生成された *.Rd ファイルだけでなく、レンダリングされた結果も含めて、非常に退屈に見える傾向があります。例えば

  1. 多くの場合、例は最小限であり、コメントが含まれておらず、適切にフォーマットされていないことがよくあります (スペース、改行、.. を使用)。
  2. \eqn{} や \deqn{} で数学的な問題が説明されることはめったにありません
  3. \describe{ .. } および同様の高レベルの書式設定はめったに使用されません

何故ですか?なぜなら

1) roxygen コメントの読み取りと編集は、ESS または Rstudio または (*.Rd サポートが組み込まれている他の IDE) での *.Rd ファイルの読み取りと編集よりもはるかに「面倒」であるか、少なくとも視覚的にやりがいがありません。

2) その文書を使用している場合

パッケージのビルド/チェックの最後に自動的に生成されるものです

あなたは通常、よく書かれたRドキュメントを重要なものとは見なさない傾向があります(むしろ、すべてのドキュメントが単なるコメントであるRコード:-)

そのすべての結果: 人々は、ビネットやブログ、github Gist、YouTube ビデオなどで関数に関するドキュメントを書くことを好みます。時代遅れになり、衰退します(したがって、Google検索を介してユーザーを誤解させます)->コードとドキュメントを同じ場所に置くというroxygenの本来の動機は完全に打ち負かされます。

私は roxygen が好きで、新しい関数を作成するときに広く使用しています...関数がパッケージに含まれていないか、エクスポートされていない限り、それを保持および維持します。エクスポートすることに決めたら、(ESS に相当する) roxygenize() を 1 回実行し、それ以降は、適切にフォーマットされ、独自のコメントを含む *.Rd ファイルを維持する というわずかな負担がかかります (作成者としての私にとって)。 、多くの素晴らしい例があり、独自のリビジョン管理 (git / svn / ...) 履歴などがあります。

于 2013-02-02T15:05:58.953 に答える
0

私とは別のパッケージで定義されたジェネリックの S4 メソッドの NAMESPACE および *.Rd ファイルを生成することができました。

次の手順を実行しました。

  1. roxygen2の既知のバグの回避策として、手動で NAMESPACE を作成します。

    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. S4 メソッドの roxygen ドキュメントに明示的な roxygen タグ @title および @description を追加します。値が @title と同じであっても、@description を明示的に記述します。

それは私にとってはうまくいきます。

于 2015-12-24T12:12:26.733 に答える