5

これは私が以前に投稿した質問のフォローアップです。要約すると、私はSlidifyと呼ばれるRパッケージを作成しています。これは、いくつかの外部の非Rベースのライブラリを利用します。私の以前の質問は、依存関係を管理する方法についてでした。

いくつかの解決策が提案されましたが、その中で最も魅力的な解決策は、外部ライブラリを別のRパッケージとしてパッケージ化し、Slidifyの依存関係にすることでした。xlsxこれは、Java依存関係を別のパッケージとしてパッケージ化するパッケージが続く戦略xlsxjarsです。

別の方法は、外部ライブラリをダウンロードとして提供し、install_librariesSlidify内の関数をパッケージ化することです。これにより、必要なファイルが自動的にフェッチされ、パッケージディレクトリにダウンロードされます。update_libraries状況が変わった場合に更新する関数を 追加することもできます。

私の質問は、Rベースではない外部ライブラリに対してCRANダンスを行うことには特定の利点がありますか？ここで何かが足りませんか？

4

1 に答える 1

3

コメントスレッドで説明されているように、多数の大きな（ほとんど）固定されたポータブルファイルを含むslidifyのようなパッケージの場合、「リソース」パッケージの方が理にかなっています。

  • あなたはそれがインストールされたパスを知っているでしょう（パッケージ自体があなたに教えてくれるので）
  • ユーザーが誤って別の場所に置くことはできません
  • CRANテストを取得します
  • あなたはCRANディストリビューション、ミラー、...を取得します
  • ユーザーはすでに知っているinstall.packages()など
  • これらの固定パーツを使用したパッケージのより機敏な開発は、大きなサポートファイルによって妨げられません。
于 2012-11-06T19:35:51.920 に答える