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 回答