1

我正在编写一个同时导入（和使用）SparkR::sql和dbplyr::sql. 其他相关 问题涉及我随意的无意碰撞import。

在我的NAMESPACE我有：

importFrom(dbplyr, sql)
importFrom(SparkR, sql)

这两个函数都在脚本中使用，并且意识到冲突，我肯定总是在包名称前面加上前缀：

dbplyr::sql(...)
SparkR::sql(...)

尽管如此，我在构建/检查包时收到了导入替换警告：

警告：在加载 'my_pkg' 时将之前的导入 'dbplyr::sql' 替换为 'SparkR::sql'</p>

我在编写 R 扩展中看到的似乎如下：

如果一个包只需要另一个包中的几个对象，它可以foo::f在代码中使用完全限定的变量引用 [ ] 而不是正式导入...这比正式导入效率略低，也失去了记录所有依赖项的优势在NAMESPACE文件中（但它们仍然需要记录在DESCRIPTION文件中）。评估foo::f将导致包foo被加载，但不附加，如果它还没有加载——这可能是延迟加载很少使用的包的一个优势。

我是否正确，这个/最佳实践的要点是：

  • 选择最常用的功能并将其添加到importFrom
  • 删除“不太频繁”的功能，importFrom但保留该包DESCRIPTION
  • 只需将::（可能在前面require()）用于“不太频繁”的功能
4

1 回答 1

3

我一直遵循这个建议：

包在描述中的导入中列出是很常见的，但在命名空间中却没有。事实上，我建议这样做：在DESCRIPTION中列出软件包以便安装它，然后始终使用pkg::fun()显式引用它。

在你的情况下：

  • 删除两者 importFrom
  • 把两个包裹都放在里面Imports:
  • 使用dbplyr::sql和SparkR::sql

我在这里的主要动机是一致性：即使没有任何名称冲突，我也希望在阅读某些函数来自的代码时始终使用全名以清楚地说明。如果我不使用importForm并且忘记在一个地方使用全名，R CMD ckeck就会发现。我认为这种代码清晰度高于在两个地方收集依赖项的（感知的）优势：描述和（更明确的）命名空间。

于 2018-09-06T08:50:49.997 回答