Devtools: Namespace löscht keine alten Informationen, wenn sich @importFrom ändert

Erstellt am 3. Jan. 2014  ·  8Kommentare  ·  Quelle: r-lib/devtools

Angenommen, ich verwalte zwei Pakete, nenne sie foo und bar . bar exportiert eine Funktion baz und foo importiert sie in die Datei help.R mit @importFrom , dh in foo/R/help.R gibt es sie eine Zeile <strong i="11">@importFrom</strong> bar baz . Wenn ich document verwende, wird die Namespace-Datei korrekt erstellt, sodass sie importFrom(bar,baz) enthält.

Angenommen, ich ändere im Paket bar den Namen von baz in bash . Ich aktualisiere foo/R/help.R auf <strong i="19">@importFrom</strong> bar bash . Wenn ich jedoch document verwende, fügt der Namespace korrekt importFrom(bar,bash) hinzu, löscht jedoch nicht importFrom(bar,baz) , sodass ich Fehler erhalte, wenn ich install .

Ich verwende das clean = TRUE -Argument und denke, das würde dies auch bereinigen, aber es scheint, als würde das nur in die Man-Dateien gehen. Übersehe ich hier etwas? Oder ist das ein Fehler?

Danke!

Hilfreichster Kommentar

Löschen Sie die Namespace-Datei und führen Sie load_all() und dann devtools::docuement() aus. Es sollte die Arbeit machen.

Alle 8 Kommentare

Verwenden Sie die neueste Version von roxygen2? Es sollte die NAMESPACE-Datei jedes Mal von Grund auf neu erstellen.

Ja, ich verwende roxygen2 v3.0.0

Sitzungsinfo()
R-Version 3.0.2 (2013-09-25)
Plattform: x86_64-apple-darwin10.8.0 (64-Bit)

Gebietsschema:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

angehängte Basispakete:
[1] Statistiken Grafikdatensätze grDevices utils Methodenbasis

andere angehängte Pakete:
[1] plyr_1.8 ...
extrafont_0.15
[25] roxygen2_3.0.0 testthat_0.7.1
[27] devtools_1.4.1

über einen Namensraum geladen (und nicht angehängt):
[1] biglm_0.9-1 boot_1.3-9 brew_1.0-6 cluster_1.14.4 codetools_0.2-8
[6] colorspace_1.2-4 corrplot_0.73 data.table_1.8.10 dichromat_2.0-0 digest_0.6.4
[11] auswerten_0.5.1 extrafontdb_1.0 formatR_0.10 Formel_1.1-1 ggplot2_0.9.3.1
[16] gmp_0.5-11 grid_3.0.2 gtable_0.1.2 Hmisc_3.13-0 httr_0.2
[21] knitr_1.5 labeling_0.2 lattice_0.20-24 lubridate_1.3.3 MASS_7.3-29
[26] memoise_0.1 munsell_0.4.2 parallel_3.0.2 proto_0.3-10 R.cache_0.9.0
[31] R.methodsS3_1.5.2 R.oo_1.15.8 R.utils_1.28.4 RColorBrewer_1.0-5 RCurl_1.95-4.1
[36] reshape2_1.2.2 rjson_0.2.13 Rttf2pt1_1.2 scales_0.2.3 splines_3.0.2
[41] stringr_0.6.2 survival_2.37-4 tools_3.0.2 whisker_0.3-2 xtable_1.7-1

Sind Sie sicher, dass Sie nicht woanders noch ein <strong i="5">@importFrom</strong> x y haben?

Nichts Offensichtliches, aber es scheint, als müsste ich etwas verweilen, wo ich es nicht erwarte. Ich werde weiter suchen; Tut mir leid, dass ich störe.

Ich eröffne dieses Problem erneut, weil ich in der Lage war, eine MWE zu erstellen, die einen Fehler im Zusammenhang mit @importFrom erzeugt (obwohl ich mir nicht ganz sicher bin, ob es mit meinem ursprünglichen Beitrag zusammenhängt).

Ich habe ein Skelettpaket mit Barebones-Dateien erstellt und nur die help.R -Datei bearbeitet, was sehr einfach ist:

#' <strong i="9">@docType</strong> package
#'
#' <strong i="10">@importFrom</strong> plyr ddply
NULL

Wenn ich document(package_directory, clean = TRUE) (wobei package_directory eine Variable ist, die den Pfad zum Paket enthält), funktioniert alles einwandfrei. Jetzt ändere ich help.R in:

#' <strong i="17">@docType</strong> package
#'
#' <strong i="18">@importFrom</strong> plyr
NULL

und rufen document(package_directory, clean = TRUE) , was wie erwartet einen Fehler verursacht:

Error in asChar(ivars) : 
  empty name in directive 'importFrom' in 'NAMESPACE' file

Gehen wir jetzt zurück und reparieren das help.R , damit es wieder das Original ist:

#' <strong i="27">@docType</strong> package
#'
#' <strong i="28">@importFrom</strong> plyr ddply
NULL

Wenn ich document(package_directory, clean = TRUE) calle, erhalte ich überraschenderweise immer noch den Fehler, den ich hatte, als ich help.R kaputt machte. Ich hätte gedacht, dass es hier gut funktioniert hätte, weil document die Datei NAMESPACE $ ignoriert.

Eine zusätzliche Wendung ist, dass es gut funktioniert, wenn ich anstelle von document nach dem Zerbrechen von Dingen roxygenize verwende.

Laut der roxygen -Dokumentation: "Wenn Sie ein einfaches Paket haben, können Sie roxygenise() verwenden, aber für etwas Komplizierteres empfehle ich Ihnen, document() zu verwenden." Warum funktioniert document hier nicht, aber roxygenize schon? Und wann sollte jeder verwendet werden?

Was die Versionen angeht bin ich auf dem neusten Stand:

> sessionInfo()
R version 3.0.3 (2014-03-06)
Platform: x86_64-apple-darwin10.8.0 (64-bit)

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats     graphics  datasets  grDevices utils     methods   base     

other attached packages:
[1] plyr_1.8.1     extrafont_0.16 roxygen2_3.1.0 testthat_0.8.1 devtools_1.4.1

Ah, das Problem ist, dass document() zuerst load_all() ausführen muss, um das Paket zu laden, und sobald Sie den Namespace beschädigt haben, gibt es keine Möglichkeit, es zu laden. In diesem Szenario mache ich normalerweise die Änderung in Git einfach rückgängig.

Löschen Sie die Namespace-Datei und führen Sie load_all() und dann devtools::docuement() aus. Es sollte die Arbeit machen.

Dieses alte Problem wurde automatisch gesperrt. Wenn Sie glauben, ein verwandtes Problem gefunden zu haben, erstellen Sie bitte ein neues Problem (mit Reprex) und verlinken Sie auf dieses Problem. https://reprex.tidyverse.org/

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen