R包装大尺寸外部资产

这是我之前发布的question的后续。总而言之，我正在编写一个名为Slidify的R包，它使用了几个外部的非R库。我之前的问题是关于如何管理依赖关系。R包装大尺寸外部资产

提出了几种解决方案，其中最有吸引力的解决方案是将外部库打包为不同的R包，并使其成为Slidify的依赖项。这是包裹xlsx所遵循的策略，它将java依赖关系打包为xlsxjars。

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

我的问题是，对于不是基于R的外部库进行CRAN舞会有没有什么特别的优势。我在这里错过了什么吗？

2012-11-06 Ramnath

忍住不做'install_libraries'黑客。使用CRAN作为中央repo和分发机制是更可取的：'install.packages（）'已经存在，更新变量等。通过重新创建一个新机制，您将简单地下降到新的未经测试的错误的滑坡。你基本上试图重塑像fink这样的发行版或系统。太复杂了。 –

感谢您的comemnt @Dirk。外部库的大小为10MB，当我读取CRAN文档时，它说明了将事情保持在5MB以下的效果。我明白你的观点，即CRAN提供了一种简单的机制，只要有可能，就可以使用它。 – Ramnath

对于xlxs和weka，它是Java吗？然后一个罐子包是有道理的。否则，你有二进制兼容性的问题，可能不得不依靠用户。 –

正如评论线程与多家大讨论，一个包状slidify，（主要是）固定和便携式文件，“资源”的包装更有意义：

2012-11-06 19:35:51

感谢您发布全面的答案@Dirk。您详细描述的优点为通过CRAN分配非R资源提供了强有力的支持。 – Ramnath

你也会得到CRAN态度... – hadley

也许我对github的自鸣得意采取CRAN态度？ ;-) –

回答