drake::expose_imports() 的正确用法 - 在哪里调用 - 它是递归的吗？
Correct usage of drake::expose_imports() - Where to place call - Is it recursive?
总结
我注意到 drake 文档中的 hints/suggestions/warnings 建议使用 expose_imports 来确保可重复地跟踪导入包中的更改，但文档在正确的方面相对简短这个的用法。
例子
我现在目睹了 expose_imports 行为的一个例子，旨在纠正我自己对 drake 的使用，我想开始使用它。
在我的例子中，未跟踪的依赖项是 forcats，在版本 0.4.0 中有一个错误 fct_collapse（由我的一个函数使用）会将不正确的组分配给输出因子。
0.4.0.9000 解决了这个错误，我在前段时间更新到 0.4.0.9000，但确实注意到针对旧版本必须具有 运行 的目标没有失效。
问题
我猜想 expose_imports 可能会缓解这个问题，但我真的不明白如何/在哪里使用它。
如果我在我的 drake 计划中对 my.package 进行范围调用，如下所示：
plan <- drake::drake_plan(
mtc = mtcars,
mtc_xformed = my.package::transfom_mtc(mtc)
)
并且my.package::transform_mtc()对另一个包有一些依赖，（例如forcats）然后：
- 我应该打电话给哪里
expose_imports？
- 在
make 的 prework 参数中?
- 在
my.package/R/ 中文件的顶层 ?
- 我应该打电话吗
expose_imports("my.package")？或者expose_imports("forcats")
对此进行一些澄清会很棒
expose_imports() 主要用于 update/reinstall 很多的包。例如，假设您编写了一个包来实现一种新的统计方法，并且该包仍在积极开发中。同时，您也在写一篇关于该方法的期刊文章，并且您有一个可重现的 drake 管道到 运行 模拟研究和编译手稿。在这里，当您对包进行更改时刷新文件很重要。在 project archetype here 中，您的 R/packages.R 文件看起来像这样：
library(drake)
library(tidyverse)
library(yourCustomPackage)
expose_imports(yourCustomPackage)
然后，该计划可以使用 yourCustomPackage.
中的函数
plan <- drake_plan(
analysis = custom_method(...) # from yourCustomPackages
# ...
)
现在，drake 将使目标失效以响应 custom_method() 中的变化，以及 custom_method() 在 yourCustomPackages 中的任何嵌套依赖函数，以及那些yourCustomPackages 中的依赖项等。（检查 vis_drake_graph() 自己看看。）
expose_imports() 通常我只推荐与你的研究内容直接相关的包。对于像 forcats 这样的实用程序，我通常不会推荐它。对于这些包，我建议 renv 以防止意外更改的发生。在你的情况下，我会更新 forcats，用 renv 锁定它，使你知道依赖 forcats 的目标无效，并相信未来对 forcats 的更改不太可能有必要。
像 my.package::transfom_mtc(mtc) 这样的作用域调用告诉 drake 跟踪 transform_mtc()，但不告诉从 my.package::transfom_mtc(mtc) 调用的任何未作用域的依赖函数。这是我不再认同的一种脚踏实地的想法行为。 Next chance I get，我会让 drake 停止跟踪这些电话。
总结
我注意到 drake 文档中的 hints/suggestions/warnings 建议使用 expose_imports 来确保可重复地跟踪导入包中的更改，但文档在正确的方面相对简短这个的用法。
例子
我现在目睹了 expose_imports 行为的一个例子，旨在纠正我自己对 drake 的使用，我想开始使用它。
在我的例子中，未跟踪的依赖项是 forcats，在版本 0.4.0 中有一个错误 fct_collapse（由我的一个函数使用）会将不正确的组分配给输出因子。
0.4.0.9000 解决了这个错误，我在前段时间更新到 0.4.0.9000，但确实注意到针对旧版本必须具有 运行 的目标没有失效。
问题
我猜想 expose_imports 可能会缓解这个问题，但我真的不明白如何/在哪里使用它。
如果我在我的 drake 计划中对 my.package 进行范围调用，如下所示：
plan <- drake::drake_plan(
mtc = mtcars,
mtc_xformed = my.package::transfom_mtc(mtc)
)
并且my.package::transform_mtc()对另一个包有一些依赖，（例如forcats）然后：
- 我应该打电话给哪里
expose_imports？- 在
make的prework参数中? - 在
my.package/R/中文件的顶层 ?
- 在
- 我应该打电话吗
expose_imports("my.package")？或者expose_imports("forcats")
对此进行一些澄清会很棒
expose_imports() 主要用于 update/reinstall 很多的包。例如，假设您编写了一个包来实现一种新的统计方法，并且该包仍在积极开发中。同时，您也在写一篇关于该方法的期刊文章，并且您有一个可重现的 drake 管道到 运行 模拟研究和编译手稿。在这里，当您对包进行更改时刷新文件很重要。在 project archetype here 中，您的 R/packages.R 文件看起来像这样：
library(drake)
library(tidyverse)
library(yourCustomPackage)
expose_imports(yourCustomPackage)
然后，该计划可以使用 yourCustomPackage.
plan <- drake_plan(
analysis = custom_method(...) # from yourCustomPackages
# ...
)
现在，drake 将使目标失效以响应 custom_method() 中的变化，以及 custom_method() 在 yourCustomPackages 中的任何嵌套依赖函数，以及那些yourCustomPackages 中的依赖项等。（检查 vis_drake_graph() 自己看看。）
expose_imports() 通常我只推荐与你的研究内容直接相关的包。对于像 forcats 这样的实用程序，我通常不会推荐它。对于这些包，我建议 renv 以防止意外更改的发生。在你的情况下，我会更新 forcats，用 renv 锁定它，使你知道依赖 forcats 的目标无效，并相信未来对 forcats 的更改不太可能有必要。
像 my.package::transfom_mtc(mtc) 这样的作用域调用告诉 drake 跟踪 transform_mtc()，但不告诉从 my.package::transfom_mtc(mtc) 调用的任何未作用域的依赖函数。这是我不再认同的一种脚踏实地的想法行为。 Next chance I get，我会让 drake 停止跟踪这些电话。