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態度？ ;-) –

回答