1

概括

我注意到drake文档中的提示/建议/警告建议使用expose_imports来确保可重复地跟踪导入包中的更改,但是文档中关于正确使用的内容相对简短。

例子

我现在目睹了一个行为示例,expose_imports旨在纠正我自己对 的使用drake,我想开始使用它。

在我的情况下,未跟踪的依赖项是forcats,它在版本0.4.0中有一个错误fct_collapse(由我的一个函数使用),它会将不正确的组分配给输出因子。

0.4.0.9000解决了这个错误,我在0.4.0.9000一段时间前更新到 ,但确实注意到必须针对旧版本运行的目标没有失效。

问题

我猜这是一个expose_imports可以缓解的问题,但我真的不明白如何/在哪里使用它。

my.package如果我像这样在我的drake计划中进行范围调用:

plan <- drake::drake_plan(
  mtc = mtcars,
  mtc_xformed = my.package::transfom_mtc(mtc)
)

并且my.package::transform_mtc()对另一个包有一些依赖,(例如forcats)然后:

  • 我应该在哪里打电话expose_imports
    • prework? make_
    • 在文件的顶层my.package/R/
  • 我应该打电话吗
    • expose_imports("my.package")? 或者
    • expose_imports("forcats")

对此进行一些澄清会很棒

4

1 回答 1

0

expose_imports()主要用于您更新/重新安装很多的软件包。例如,假设您编写了一个包来实现一种新的统计方法,并且该包仍在积极开发中。同时,您还在撰写有关该方法的期刊文章,并且您拥有可重复的drake管道来运行模拟研究和编译手稿。在这里,当您对包进行更改时刷新纸张很重要。在此处的项目原型中,您的R/packages.R文件将如下所示:

library(drake)
library(tidyverse)
library(yourCustomPackage)
expose_imports(yourCustomPackage)

然后,该计划可以使用yourCustomPackage.

plan <- drake_plan(
   analysis = custom_method(...) # from yourCustomPackages
   # ...
)

现在,drake将响应 in 的变化使目标失效,以及 in的custom_method()任何嵌套依赖函数,以及那些依赖 in 的依赖等。(检查自己看看。)custom_method()yourCustomPackagesyourCustomPackagesvis_drake_graph()

expose_imports()通常我只推荐与您的研究内容直接相关的软件包。这不是我通常推荐的实用程序,如forcats. 对于这些软件包,我建议renv从一开始就防止发生意外更改。在你的情况下,我会更新forcats,锁定它renv,使你知道依赖的目标无效forcats,并相信未来的更改forcats不太可能是必要的。

范围调用,如my.package::transfom_mtc(mtc)tell draketo track transform_mtc(),但不是任何无范围的依赖函数 from 调用my.package::transfom_mtc(mtc)。这是我不再同意的一脚进一脚的想法行为。下次有机会,我将drake停止跟踪这些电话。

于 2020-01-23T18:32:49.670 回答