R包装与大型外部资产

Ram*_*ath 5 r package

这是我之前发布的问题的后续内容.总而言之,我正在编写一个名为Slidify的R包,它使用了几个外部非基于R的库.我之前的问题是如何管理依赖项.

提出了几种解决方案,其中最有吸引力的解决方案是将外部库打包为不同的R包,并使其成为Slidify的依赖.这是程序包遵循的策略xlsx,它将java依赖项打包为另一个程序包xlsxjars.

一个替代方案是我提供外部库作为下载并install_libraries在Slidify中打包一个函数,它将自动获取所需的文件并将其下载到包目录中.我还可以添加一个update_libraries功能,如果事情发生变化会更新.

我的问题是,对于非基于外部库的CRAN舞蹈是否有任何特定的优势.我在这里错过了什么吗?

Dir*_*tel 3

正如评论线程中所讨论的,对于像 slidify 这样具有大量大型(大部分)固定且可移植文件的包,“资源”包更有意义:

  • 您将知道它的安装路径(正如软件包本身会告诉您的那样)
  • 用户不能意外地将其放在其他地方
  • 你接受 CRAN 测试
  • 你会得到 CRAN 发行版、镜像、...
  • 用户已经知道install.packages()
  • 使用这些固定部件更灵活地开发软件包不会受到大型支持文件的阻碍