2016-05-16 5 views
3

Bei der Entwicklung eines R-Pakets ist es für mich üblich, Packrat einfach zu aktivieren und ein lokales Repository zu verwenden und es so zu entwickeln, wie ich es in einer Sitzung erkunde. Aber bei der Veröffentlichung des Pakets ist es ein großes Problem, alle Abhängigkeiten, die ich in dem entwickelten Paket verwendet habe, wiederzugeben und manuell hinzuzufügen. Gibt es einen (halb-) automatischen Weg, dies zu tun? In der NodeJS-Entwicklung können wir einfach npm install --save verwenden und die Abhängigkeit wird automatisch zu package.json hinzugefügt.Gibt es eine Möglichkeit, den Abschnitt "Imports" in der Datei DESCRIPTION automatisch zu generieren?

+1

Ich denke, * * Der normale Weg, dies zu tun ist manuell roxygen (2) '@ importFrom' Anweisungen in den Code einfügen ... –

+1

Zumindest ist es ein extrem _common_ Weg. – joran

+0

@joran: bessere Wege? (oder meinen Sie die Tatsache, dass (AFAIK) old-school/R-core-Entwickler nicht dazu neigen, roxygen zu verwenden?) –

Antwort

3

Ein üblicher Weg, dies zu tun (wenn auch nicht eine, die viel von der „alten Schule“ R-Programmierer verwendet wird, die soweit ich von Hand ihre NAMESPACE Dateien pflegen wissen ...) manuell @importFrom Aussagen in der einfügen roxygen2 Code ... z

obwohl es sicherlich hilfreich wäre, ein automatisiertes System zu haben, um Hinweise zu geben, wenn nichts anderes. Gewiss, Abhängigkeiten auf diese Weise zu pflegen (sicherzustellen, dass für jede Funktion, die eine Abhängigkeit hat, @importFrom Anweisungen hinzuzufügen) ist besser als zu versuchen, zu verfolgen, wenn Abhängigkeiten (noch) benötigt werden nach Entwicklung des Codes.

  • @import und @importFrom (die import und importFrom Aussagen übersetzen) sind sowohl legal, die R extensions guide sagt

    importFrom Verwendung selektiv statt Import gute Praxis und vor allem empfohlen, wenn sie von Paketen mit mehr als einem Import Dutzend Exporte.

("good practice" übersetzt "CRAN Maintainer wird schreien, wenn Sie dies nicht tun", ...)

  • Ich weiß nicht, ob es einen Weg gibt, zu tun importFrom versioniert Anweisungen: R setzt Paket Versionsabhängigkeiten in das Imports: Feld in der DESCRIPTION Datei und importFrom Anweisungen in der Datei NAMESPACE: roxygen2 generiert diese Informationen automatisch, aber ich glaube nicht, dass die Zuordnung von Roxygen2-Richtlinien zu /DESCRIPTION informieren Die Konfiguration ist feinkörnig genug, um dies zu unterstützen ...
  • Die Ausführung R CMD check --as-cran gibt Hinweise zu Funktionen von empfohlenen Paketen, die importiert werden müssen.
3

Ja, verwenden Sie roxygen2, um Ihre NAMESPACE Datei zu generieren.

Beispiel Art und Weise Paketebene Dokumentation zu generieren:

#' @details 
#' \tabular{ll}{ 
#' Package: \tab \cr 
#' Type: \tab Package\cr 
#' Version: \tab 1.0.0\cr 
#' Date: \tab 2016-05-15\cr 
#' License: \tab MIT \cr 
#' } 
#' @useDynLib pkg 
#' @importFrom Rcpp evalCpp 
#' @importFrom methods is 
#' @importFrom stats ts as.ts is.ts 
#' @import ggplot2 
"_PACKAGE" 

Hinweis: Ich neige dazu, halten meine Import-Anweisungen zusammen im Paket-Level-Dokumentation. Sie können diese Anweisungen in der Funktionsdokumentation verwenden.

Verwenden Sie @importFrom <pkg> <function1> <function2> für bestimmte Importe.

Ansonsten verwenden Sie @import <pkg> für alle Funktionen in einem bestimmten Paket.

bearbeiten

Um es auf eine bestimmte Version zu sperren, müssen Sie Ihre DESCRIPTION Datei Imports: Abschnitt wie so ändern:

Imports: 
    Rcpp (>= 0.12.5), 
    scales (<= 0.4.0), 
    grid (== 0.7-4), 
    stats 
+0

Handelt es sich um bestimmte Versionen? Denken Sie, dass es überflüssig ist, Roxygen2 und Packrat für die Behandlung von Abhängigkeiten zu verwenden? – trVoldemort

+0

Ich bevorzuge Import-Anweisungen mit der Funktionsdokumentation, weil es klar macht * wo * im Code Sie eine bestimmte Funktion benötigen - wenn dieser Code später verschwindet, wissen Sie, dass Sie die Abhängigkeit nicht mehr brauchen. –

+1

Beachten Sie die Bearbeitung für versionsspezifische Paketladungen. @BenBolker Ich finde es einfacher, alles zu zentralisieren und den Paket-Namespace voranzustellen, wenn die Funktion des Pakets aufgerufen wird, z. 'stats :: is.ts()' da ich selten Abhängigkeiten entferne. Wiederum ist jeder Ansatz gültig. – coatless

Verwandte Themen