Идентификация имени файла Rd при расширении метода S4 другого пакета

Актуальный вопрос

Как избежать конфликтов имен файлов Rd при

  • S4 generic и его метод не обязательно должны быть определены в одном пакете (пакет, содержащий (некоторые)) настраиваемый метод (ы), зависит от пакета, содержащего общий) и
  • используя roxygenize() из пакета roxygen2 для создания реальных файлов Rd?

Я не уверен, что это проблема roxygen2 или общая проблема, когда общий и их методы разбросаны по пакетам (что ИМХО в целом определенно является реалистичным сценарием для использования, если вы следуете модульный стиль программирования).

Какой рекомендуемый способ справиться с этими ситуациями?

Иллюстрация

В пакете pkga

Предположим, что в пакете pkga вы определили общий метод foo и что вы предоставили соответствующий код roxygen, который roxygenize() выбирает для создания Rd файла:

#' Test function
#' 
#' Test function.
#' 
#' @param ... Further arguments.
#' @author Janko Thyson \email{[email protected]@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() ваш пакет, в подкаталоге man создается файл с именем foo-methods.Rd, который служит в качестве ссылочного Rd файла для всех методов, которые могут быть созданы для этого общего метода. Все идет нормально. Если все методы этого родословного также являются частью вашего пакета, все хорошо. Например, этот код-роуд-код будет обеспечивать добавление документации к foo-methods.Rd для ANY -метода 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) добавить foo -метод для x класса character, тогда R CMD check сообщит вам, что существует столкновение имен в отношении имен файлов Rd и/или псевдонимов (так как в файле pkga уже существует файл Rd foo-methods.Rd):

В пакете 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'

Due dilligence

Я попытался изменить значения для @rdname и @aliases на foo_pkgb* (вместо foo*), но \title и \name все еще настроены на foo при роугенировании и, следовательно, ошибке остается. Любые идеи помимо ручного редактирования файлов Rd, сгенерированных roxygenize()?


EDIT 2012-12-01

В свете начала щедрости реальный вопрос может получить чуть более широкий вкус:

Как мы можем реализовать некоторую проверку "межпакетов" в отношении файлов Rd и/или как мы можем консолидировать файлы справки по методу S4, разбросанные по пакетам, в один Rd файл, чтобы представить один источник ссылки на конечного пользователя?

Ответ 1

Основной вопрос - действительно "роксигенизировать" - только. Вот почему я никогда не видел проблемы.

Несмотря на то, что существуют обоснованные причины для подхода, основанного на роксигенизации разработки пакета, Я по-прежнему вижу очень хорошую причину не:

Просьба о гораздо меньшей степени оксигенации

В результате страницы справки имеют тенденцию выглядеть скучно чрезвычайно, а не только автоматически сгенерированные *.Rd файлы, но также и результат рендеринга. Например.

  • примеры часто минимальны, не содержат комментариев, часто не очень хорошо отформатированы (используя пробел,/новые строки /..)
  • Математические вопросы редко объясняются с помощью \eqn {} или \deqn {}
  • \описать {..} и подобное форматирование более высокого уровня редко используется

Почему? Потому что

1) чтение и редактирование комментариев roxygen - это намного больше "громоздким" или, по крайней мере, визуально неприемлемым  чем чтение и редактирование *.Rd файлов в ESS или Rstudio или (другая среда разработки, в которой встроена поддержка *.Rd)

2) Если вы используете эту документацию

- это то, что автоматически генерируется в конце сборки вашего пакета/проверки

вы обычно склонны не рассматривать хорошо написанную документацию R как нечто важное (но скорее ваш R-код, для которого все документы являются просто комментарием: -)

Результат всего этого: люди предпочитают писать документацию об их функциях в виньетках или даже блогах, github gists, youtube videos или... там, где это очень хорошо на момент создания, но есть в значительной степени отделился от кода и стал устаревшим и увядающим (и, следовательно, с помощью Google вводил в заблуждение ваш useRs)  - > Оригинальная мотивация roxygen наличия кода и документации в том же месте полностью побеждена.

Мне нравится roxygen и широко использую его во время создания новой функции... и я сохраняю и поддерживаю его, пока моя функция не находится в пакете, или не экспортируется. Как только я решил экспортировать его, Я запускаю (эквивалент ESS) roxygenize() один раз и с тех пор возьмите небольшое бремя поддержки файла *.Rd, который хорошо отформатирован, содержит свои собственные комментарии (для меня как автора), имеет много хороших примеров, имеет свой собственный контроль версий (git/svn/...) история и т.д.

Ответ 2

Мне удалось создать файлы NAMESPACE и *.Rd для методов S4 для генериков, определенных в другом пакете, чем у меня.

Мне потребовались следующие шаги:

  • Создайте NAMESPACE вручную в качестве обходной возможности известной ошибки roxygen2.

    Написание NAMESPACE вручную не так сложно!

    Отключите генерацию NAMESPACE с помощью roxygen2 в RStudio:

    Build > more > Configure build tools > configure roxygen > do not use roxygen2 to generate NAMESPACE.
    
  • импортировать пакет, содержащий общий тип, и экспортировать методы S4 с помощью методов exportMethods.

  • Напишите отдельную документацию roxygen2 для каждого из методов S4. Не комбинируйте документацию roxygen2 (как я обычно делаю для разных методов того же родового).

  • Добавьте явные теги roxygen @title и @description в документацию roxygen методов S4. Напишите @description явно, даже если его значение идентично @title.

Это заставляет меня работать для меня.