在 functions/packages 中使用 data.table(使用氧气)

Use data.table in functions/packages (With roxygen)

我是R的新手,但看来,这个问题与以下post 1, , 3 and a bit different topic 4密切相关。不幸的是,我没有足够的声望在那里发表评论。我的问题是,在阅读了那里的所有建议之后,代码仍然不起作用:

  1. 我在描述文件中包含了"Depends"
  2. 我尝试了第二种方法,包括更改 NAMESPACE (不可重现)
  3. 我创建了一个 示例包 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)])
  4. 我使用控制台和 R 脚本测试了所有脚本。还有,代码运行没有问题。

非常感谢您的支持!

编辑:@Roland

  1. 你是对的。 Roxygen 覆盖命名空间。您必须在函数中包含 #' @import data.table。你明白吗,为什么只在 DESCRIPTION 文件中插入 Depends: data.table 不起作用?这可能是文档中的有用提示,还是我错过了?
  2. 更改为 routes <- routes[order("lat1", "lng1", "lat2", "lng2", "time")] 有帮助是误导至少有一点,因为这条线突然就没问题了。在这种情况下使用 data.frame 顺序是否正确?我会看看我现在能走多远。我会告诉你最后的结果...

回答您的问题(编辑后)。

  1. 引用 R exts 手册:

Almost always packages mentioned in ‘Depends’ should also be imported from in the NAMESPACE file: this ensures that any needed parts of those packages are available when some other package imports the current package.

因此,尽管您依赖或导入 data.table。

,但您仍然应该在 NAMESPACE 中导入
  1. order 调用似乎不是您所期望的,请尝试以下操作:

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

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

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

这是对上述答案的补充:我发现这真的很有用...

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

Imports packages listed here must be present for your package to work. In fact, any time your package is installed, those packages will, if not already present, be installed on your computer (devtools::load_all() also checks that the packages are installed).

Adding a package dependency here ensures that it’ll be installed. However, it does not mean that it will be attached along with your package (i.e., library(x)). The best practice is to explicitly refer to external functions using the syntax package::function(). This makes it very easy to identify which functions live outside of your package. This is especially useful when you read your code in the future.

If you use a lot of functions from other packages this is rather verbose. There’s also a minor performance penalty associated with :: (on the order of 5$\mu$s, so it will only matter if you call the function millions of times).

来自文档 Hadley-namespace

NAMESPACE also controls which external functions can be used by your package without having to use ::. It’s confusing that both DESCRIPTION (through the Imports field) and NAMESPACE (through import directives) seem to be involved in imports. This is just an unfortunate choice of names. The Imports field really has nothing to do with functions imported into the namespace: it just makes sure the package is installed when your package is. It doesn’t make functions available. You need to import functions in exactly the same way regardless of whether or not the package is attached.
... this is what I recommend: list the package in DESCRIPTION so that it’s installed, then always refer to it explicitly with pkg::fun(). Unless there is a strong reason not to, it’s better to be explicit. It’s a little more work to write, but a lot easier to read when you come back to the code in the future. The converse is not true. Every package mentioned in NAMESPACE must also be present in the Imports or Depends fields.