在函数/包中使用 data.table（使用 roxygen）答案

【问题标题】：Use data.table in functions/packages (With roxygen)在函数/包中使用 data.table（使用 roxygen）
【发布时间】：2016-08-19 22:33:47
【问题描述】：

我对 R 很陌生，但似乎这个问题与以下帖子密切相关 1、2、3 和一个有点不同的主题 4。不幸的是，我没有足够的声誉来发表评论。我的问题是，在查看了那里的所有建议后，代码仍然不起作用：

我在描述文件中包含了“Depends”
~~我尝试了第二种方法，包括更改 NAMESPACE~~ （不可重现）
我创建了一个示例包 here，其中包含一小部分代码，显示出一些不同的错误（"J" not found in routes[J(lat1, lng1, lat2, lng2), .I, roll = "nearest", by = .EACHI] 而不是'lat1' not found in routes[order(lat1, lng1, lat2, lng2, time)]）
我使用控制台和 R 脚本测试了所有脚本。在那里，代码运行没有问题。

非常感谢您的支持！

编辑：@Roland

你是对的。 Roxygen 会覆盖命名空间。您必须在函数中包含#' @import data.table。你明白吗，为什么只在DESCRIPTION文件中插入Depends: data.table是行不通的？这可能是文档中的有用提示，还是我错过了？
更改为路线

【问题讨论】：

1) 将 data.table 添加到 Imports（不依赖），2) 将 import(data.table) 添加到 NAMESPACE 文件。而已。您是否可能使用 roxygen2，它可能会重写您的 NAMESPACE 文件？
如果您还没有阅读：R-exts manual

标签： r windows data.table testthat

【解决方案1】：

回答您的问题（编辑后）。

引用 R exts 手册：

“Depends”中提到的包几乎总是应该从 NAMESPACE 文件中导入：这样可以确保当其他包导入当前包时，这些包的任何需要的部分都可用。

因此，尽管您依赖或导入 data.table，但您仍然应该在 NAMESPACE 中导入。

order 调用似乎不是您所期望的，请尝试以下操作：

order("lat1", "lng1", "lat2", "lng2", "time")

library(data.table)
data.table(a=2:1,b=1:2)[order("a","b")]

如果出现问题，我建议通过为您的预期结果编写单元测试来开始调试。将单元测试放入包中的最基本方法是在tests 目录中调用stopifnot(...) 的纯R 脚本。请注意，您需要在脚本开始时库/需要您的包。

【讨论】：

好的。这意味着答案 1。here 不正确？ order 的问题现在工作正常。我只是想知道原因是否（我没有更改 NAMESPACE！）它是一个 data.frame order 函数。我说的对吗？
@Christoph 如果您在 data.table 中使用它，那么 AFAIK 它不是基本订单，除非您在 data.table 选项中关闭优化或直接调用 base::order
请注意，随着基础 R 合并 data.table 顺序函数，它将很快在 R 3.3.0 中更改。有关详细信息，请参阅NEWS file for R 3.3.0。
好的。那么上面参考文献中的第一个答案呢？那么我认为这是错误的？
它可能无法反映当前的 R 版本要求。我刚才确实更新了它，将在 data.table 常见问题解答中跟进更新。

【解决方案2】：

除了上面的答案之外，还有更多：我发现这真的很有用......

来自文档 [Hadley-description](http://r-pkgs.had.co.nz/description.htmlund)

此处列出的进口包必须存在于您的包中工作。事实上，任何时候你的包被安装，那些包将（如果尚未存在）安装在您的计算机上（devtools::load_all() 还会检查包是否已安装）。

在此处添加包依赖项可确保安装它。但是，这并不意味着它会随您的包（即库（x））。最佳做法是明确提及使用语法package::function() 到外部函数。这可以很容易地识别哪些函数存在于您的外部包裹。这在您阅读您的代码时特别有用未来。

如果您使用其他软件包中的大量功能，则冗长。还有与相关的轻微性能损失 ::（大约 5$\mu$s，所以只有调用运行数百万次）。

来自文档Hadley-namespace

NAMESPACE 还控制您可以使用哪些外部函数包而不必使用::。令人困惑的是两者描述（通过导入字段）和命名空间（通过导入指令）似乎涉及进口。这只是一个不幸的名字选择。 Imports 字段真的没有什么可做的处理导入命名空间的函数：它只是确保软件包在您的软件包安装时安装。它不产生函数可用的。您需要以完全相同的方式导入函数无论是否附上包裹。
... 这是我推荐的：在DESCRIPTION中列出包，以便它安装，然后始终使用pkg::fun() 明确引用它。除非有充分的理由不这样做，否则最好是明确的。写起来有点麻烦，但是当你阅读时会更容易阅读以后再回来看代码。反之则不成立。每一个 NAMESPACE 中提到的包也必须存在于 Imports 或取决于字段。

【讨论】：