58 votes

Rd conflit de nom de fichier lors de l'extension d'un S4 méthode d'un autre paquet

Libellé de la question

Comment puis-je éviter de Rd de nom de fichier lors de conflits

  1. un S4 générique et sa méthode(s) sont pas nécessairement tous définis dans le même package (package contenant (une partie de) la méthode personnalisée(s) dépend du colis contenant les produits génériques) et de
  2. à l'aide de roxygenize() de colis roxygen2 pour générer le réel Rd fichiers?

Je ne suis pas sûre que ce soit une roxygen2 problème ou un problème courant lorsque le générique et sa méthode(s) sont dispersés à travers les paquets (qui à mon humble avis, en général, est certainement réaliste d'un scénario du cas d'utilisation si vous suivez une programmation modulaire de style).

Quelle est la méthode recommandée pour le traitement de ces situations?

Illustration

Dans le paquet pkga

Supposons que dans le paquet pkga vous avez défini une méthode générique foo et que vous avez fournis à la respectif roxygen code roxygenize() ramasse pour générer la Rd fichier:

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

Lors de l' roxygenizing() de votre colis, un fichier appelé foo-methods.Rd est créé dans l' man sous-répertoire qui sert de référence Rd fichier pour toutes les méthodes qui pourraient être créés pour cette méthode générique. So far So good. Si toutes les méthodes pour ce générique sont également le cadre de votre forfait, tout est bon. Par exemple, ce roxygen code serait de s'assurer que la documentation est ajouté à l' foo-methods.Rd de la ANY-méthode de 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))
)

Toutefois, si le paquet pkga fournit le générique pour foo et que vous décidez dans un autre paquet (disons pkgb) pour ajouter un foo-méthode de x étant de la classe character, alors R CMD check vous dira qu'il y a un conflit de nom avec respect à la Rd noms de fichiers et/ou des alias (comme il en existe déjà un Rd fichier foo-methods.Rd en pkga):

Dans le paquet 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))
)

Pour être plus précis, c'est l'erreur qui est jeté/écrites dans le fichier 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 diligence

J'ai essayé de modifier les valeurs de @rdname et @aliases de foo_pkgb* (au lieu de foo*), mais \title et \name sont encore ensemble à l' foo lorsque roxygenizing et donc l'erreur reste. Des idées en plus de la modification manuelle de la Rd fichiers générés par roxygenize()?


EDIT 2012-12-01

À la lumière de commencer la générosité, la question réelle pourrait obtenir un peu plus large de la saveur:

Comment pouvons-nous mettre en œuvre une sorte de "inter-paquets" vérifier à l'égard de Rd des fichiers et/ou comment pouvons-nous consolider S4 méthode fichiers d'aide dispersés à travers les paquets en un seul Rd fichier afin de présenter une seule source de référence pour l'utilisateur final?

4voto

Martin Mächler Points 977

La question de base est en effet "roxygenize". C'est pourquoi je ne l'avais jamais vu le problème.

Bien qu'il existe de bonnes raisons pour le roxygenizing approche de développement de package, Je vois encore une très bonne raison de ne pas y aller:

Plaidoyer pour beaucoup moins extrêmes roxygenation

La résultante des pages d'aide ont tendance à regarder très ennuyeux, pas seulement la génération automatique *.Rd fichiers, mais aussi le résultat du rendu. E. g.

  1. les exemples sont souvent minimes, ne contiennent pas de commentaires, ne sont souvent pas bien formaté (utilisation de l'espace, / nouvelles lignes..)
  2. Les questions mathématiques sont rarement expliquées par \eqn{} ou \deqn{}
  3. \décrire{ .. } et plus niveau de la mise en forme est rarement utilisé

Pourquoi est-ce? Parce que

1) lecture et d'édition de roxygen commentaires, c'est tellement plus "lourdeur" ou au moins visuellement ingrate de la lecture et de l'édition *.Rd fichiers dans l'ESS ou Rstudio ou (autre IDE que a *.Rd prise en charge intégrée)

2) Si vous avez l'habitude que de la documentation

est la chose qui est généré automatiquement à la fin de votre construction de paquet/vérification

vous avez généralement tendance à ne pas considerung bien écrit R de la documentation comme quelque chose d'important (mais plutôt votre R code, à laquelle tous les docs est juste un commentaire :-)

Le résultat de tout ça: les Gens préfèrent la rédaction de la documentation sur leurs fonctions dans les vignettes ou même les blogs, github, des vidéos youtube ou ... où il est très agréable au moment de la rédaction, mais il est assez bien détaché du code et lié à devenir obsolète et withering (et donc, via Google recherche trompeuse vos utilisateurs). --> La motivation initiale de roxygen d'avoir le code et la documentation dans le même lieu est entièrement défait.

J'aime roxygen et les utilisent beaucoup à l'époque, je créer une nouvelle fonction... et je le garder et de le maintenir aussi longtemps que ma fonction n'est pas dans un paquet, ou n'est pas exporté. Une fois que je décide de les exporter, Je (l'ESS équivalent), roxygenize() une fois et à partir de là, prendre le petit extra charge du maintien d'un *.Rd fichier est bien formaté, contient ses propres commentaires (pour moi en tant qu'auteur), a de nombreux bons exemples, dispose de son propre contrôle de révision (git / svn / ...) de l'histoire, etc.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X