複数のパッケージ管理システムに関する良い習慣
一部のプログラミング言語には、独自のパッケージ管理システムが付属しています。たとえば、Rの場合、組み込みinstall.packagesコマンドはCRANリポジトリからインストールし、依存関係を扱います。
同時に、OSには、DebianベースのLinuxディストリビューションのaptコマンドのような独自のパッケージ管理システムが付属しています。
私は、システムのすべてのものが互換性があることを保証するために、ディストリビューションのパッケージマネージャーを使用する方が良いと判断しました（ https://stackoverflow.com/a/31293955/1878788 を参照）。
しかし、すぐには、この方法では利用できないものが必要になる日がやって来ました。たとえば、私のディストリビューションでパッケージ化されていないバイオインフォマティクスプログラムは、Rの特定のバージョンを必要とします。このプログラムは、バイオインフォマティクス用のRパッケージを提供し、パッケージが相互に互換性がある（ https://www.bioconductor.org/install/#why-biocLite を参照）。
それで、私はRに私のOSパッケージ管理システムを使用しないことを決定し、生体伝導体プロジェクトによって提供されたbiocLiteコマンドを使用してすべてをインストールしました。
このアプローチはしばらくの間スムーズに実行されましたが、一貫性のある、健康的で再構築が容易なバイオインフォマティクスエコシステムを維持するために、condaパッケージ管理システムを使用することに決めた人がいることを発見しました。このプロジェクトは「bioconda」と呼ばれ、Rパッケージだけでなく、あらゆる種類の言語のものが提供されており、バージョンを簡単に切り替えることができます（ https://bioconda.github.io/ を参照）。 =）。
次に、代わりにこのアプローチを使用することにしました。bioconda/ condaで提供されていないRパッケージが必要になるまで、スムーズに実行されました。それは非常に簡単だと思われますが、condaパッケージを作成する私の試みは失敗しました。その後、生体伝導体の方法を使用してパッケージをインストールしようとしましたが、再び失敗しました。どういうわけか、パッケージ構築メカニズムが間違ったRインストールを使用していたようです。そこで、私は（まだ非常に若い）condaのインストールを削除して、私のバイオコンダクターエコシステムに戻ることにしました。
あるアプローチから別のアプローチにどれだけの期間ジャンプしなければならないのかと思っています。これらの複数の、干渉する、重複するレベルのパッケージ管理に対処する方法に関して、一般的な良い習慣はありますか？
編集（14/09/2017）：私が検討したさらに別のオプションは、 Guix のような代替のOSレベルのパッケージマネージャーを使用することです=または Nix 。
R（REnvについて聞いた）で何が利用できるかはわかりませんが、Pythonの場合、すべてのユーザーが自分の責任を負うという実際的なアプローチを決定しましたPython pyenvを使用した環境（perlbrewおよびRuby with RVM）を使用するPerlにも同じことが当てはまります。これにより、ユーザーは私の助けなしにすべてのプロジェクトに独自の最適な環境（pyenvはPythonインストールを管理し、pipを使用してその特定のローカルモジュールをインストールすることができますPythonインストール）。
システムパッケージは、システムのニーズにのみ使用されます。
通常は、システムパッケージマネージャーを使用することをお勧めします。しかし、最新の言語を使用している場合、高速で安定した配布には、新しいパッケージとバージョンが含まれません。また、あまり人気のないパッケージをリポジトリに含めることはできません。
つまり、その場合の最善の方法は、言語の組み込み関数を使用することです。 R作成者がパッケージを管理するための公式ツールを作成する場合、それは素晴らしいことですが、非公式ツールを使用することはやや危険です。