複数のパッケージ管理システムに関する優れた実践

一部のプログラミング言語には独自のパッケージ管理システムが付属しています。たとえば、Rの場合、組み込みinstall.packagesコマンドはCRANリポジトリからインストールされ、依存関係を処理します。

並行して、OSには、aptDebianベースのLinuxディストリビューション用のコマンドなど、独自のパッケージ管理システムが付属しています。

私は、システム上のすべてのものに互換性があることを保証するために、ディストリビューションのパッケージマネージャーを使用する方が良いと判断しました（/programming//a/31293955/1878788を参照）。

しかし、すぐに、この方法では入手できないものが必要になりました。たとえば、私のディストリビューションでパッケージ化されていないバイオインフォマティクスプログラムには、特定のバージョンのRが必要です。たまたま「バイオコンダクター」というプロジェクトを通じてプログラムが利用可能でした。相互に互換性がある（https://www.bioconductor.org/install/#why-biocLiteを参照）。

そこで、RにはOSパッケージ管理システムを使用せずbiocLite、生体伝導体プロジェクトが提供するコマンドですべてをインストールすることにしました。

このアプローチはしばらくの間スムーズに実行されましたが、一貫性のある健全で簡単に再構築可能なバイオインフォマティクスエコシステムを維持するために、一部の人々はcondaパッケージ管理システムを使用することに決めました。「bioconda」と呼ばれるこのプロジェクトは、Rパッケージだけでなく、あらゆる種類の言語のものを提供し、バージョンの切り替えなどを簡単に行うことができます（https://bioconda.github.io/を参照）。

その後、代わりにこのアプローチを使用することにしましたが、bioconda / condaで提供されていないRパッケージが必要になるまでスムーズに実行されました。おそらく非常に簡単ですが、condaパッケージを作成する私の試みは失敗し、その後、生体伝導体の方法を使用してパッケージをインストールしようとしましたが、再び失敗しました。どういうわけか、間違ったRインストールがパッケージビルドメカニズムによって使用されていた印象があります。それで、私は（まだ非常に若い）コンダのインストールを消去し、私のバイオコンダクターのエコシステムに戻ることにしました。

あるアプローチから別のアプローチにジャンプするのにどれくらいの時間がかかるかと思っています。これらの複数の、干渉する、重複するレベルのパッケージ管理に対処する方法に関して、一般的なグッドプラクティスはありますか？

編集（14/09/2017） ：しかし、私は考えられて別のオプションは次のように、代替OSレベルパッケージマネージャを使用することですGuixまたはニックス。

R（REnvについて聞いた）で何が利用可能かはわかりませんが、Pythonの場合、すべてのユーザーが独自のPython環境を担当するという実用的なアプローチを決定しましたpyenv（Perl with perlbrewやRuby withにも同じですRVM）。そうpyenvすれば、ユーザーは私の支援なしですべてのプロジェクトに最適な環境を作成できます（Pythonインストールを管理pipしてから、その特定のPythonインストールのローカルモジュールをインストールするために使用できます）。

システムパッケージは、システムのニーズにのみ使用されます。

通常、システムパッケージマネージャーを使用することをお勧めします。しかし、最新の言語を使用している場合、高速で安定した配布には新しいパッケージとバージョンが含まれません。また、あまり人気のないパッケージをリポジトリに含めることはできません。

したがって、その場合の最良の方法は、言語の組み込み関数を使用することです。R作成者がパッケージを管理するための公式ツールを作成する場合、それは素晴らしいことですが、非公式ツールを使用することは多少危険です。