概要
最近、私のアプリケーションの 1 つが依存しているフレームワークの作成者と会話をしました。その会話の中で、彼は余談として、彼のフレームワークを自分のアプリケーションにバンドルし、自分のコードと一貫性があることがわかっているバージョンをエンド ユーザーに配信すれば、私の生活はよりシンプルになるだろうと述べました。直観的に、私は常にこれを避けようとしてきました。実際、プロジェクト全体を使用せずにコードの一部を再配布できるように、自分のコードをセグメント化するのに苦労しました (たとえ誰かが再利用する可能性がほとんどなかったとしても)。それ）。しかし、しばらく考えてみたところ、なぜこれを行うのか特に正当な理由を思いつくことができませんでした. 実際、考えてみると、バンドルするのにかなり説得力のあるケースが見えてきました。私のすべての小さな依存関係。私は賛否両論のリストを思いついた.誰かが私が見逃しているものを指摘できることを願っている.
長所
- バージョンの一貫性は、テストとトラブルシューティングが容易になることを意味します。
- インストールするコンポーネントが少ないように見えるため、アプリケーションはより多くのユーザーに届く可能性があります。
- 依存関係の小さな調整は、アップストリームのコード ベースに浸透するのを待つよりも、ダウンストリームで簡単に作成してアプリケーションと共に配信できます。
短所
- 依存関係を含めるためのより複雑なパッケージ化プロセス。
- ユーザーは、自分のマシンに依存関係の複数のコピーを作成することになる場合があります。
- bortzmeyer の回答によると、個々のコンポーネントをアップグレードできないという潜在的なセキュリティ上の懸念があります。
ノート
参考までに、私のアプリケーションは Python で書かれており、参照している依存関係は「軽い」ものです。つまり、小さく、あまり一般的に使用されていないということです。(したがって、それらはすべてのマシンやすべてのリポジトリに存在するわけではありません。) また、アプリケーションを「パッケージ化する」と言うときは、パッケージ内にあるスクリプトを使用してインストールするのではなく、独自のソース ツリーの下に配布することを意味します。バージョンが競合する可能性はありません。また、Linux のみで開発しているため、Windows のインストールの問題について心配する必要はありません。
そうは言っても、パッケージの依存関係のより広い（言語に依存しない）問題についての考えも聞きたいです。私が見逃しているものはありますか、それとも私が考えすぎているという簡単な決定ですか?
補遺1
私は下流のパッケージャーのニーズにも非常に敏感であることは言及しておく価値があります。ディストリビューション固有の Deb または RPM でアプリケーションをラップするのは、できるだけ簡単にしたいと考えています。