ライブラリがすべてのプログラムにバンドルされているのではなく、別々に出荷されるのはなぜですか？

これが一般的に優れている理由はわかっています。より速いセキュリティ修正、より簡単なパッケージ、より多くの機能。ただし、一部の同僚に、ライブラリをプログラムにバンドルする必要がないことを説得しようとしています。このライブラリなしでは動作しませんが、ライブラリはしばらく安定しており、当面はそうです。バンドルを解除しない理由はありません。

それらを説得するためにどのような議論を使用できますか？

私の具体的な状況は次のとおりです。私はSymPyに取り組んでいます。これは、シンボリック数学用のオープンソースのPythonライブラリです。その核となる部分はmpmathです。これは、マルチビジョン浮動小数点演算用のライブラリです。SymPyはmpmathなしでは機能しません。代替手段はありません。そのため、最初からSymPyにバンドルされています（通常、新しいバージョンがインポートされるたびに修正する非互換性はわずかであると言われていました）。また、mpmathの開発者はSymPy開発に関与していたことにも注意してください。mpmathのバンドル解除に関する問題が発生しました。ここですべて読むことができます。

そこでの議論を要約すると：

バンドル解除：

• Python 3への移植がやや簡単（マイナーな議論IMHO）

• 配布のためのより簡単なパッケージ化

• ユーザーへのより高速な（セキュリティ）機能の更新

• 「依存関係のパッケージ化と処理は難しい問題ですが、解決されています。これは、私たちが独自にすべきことではありません。」

同梱を続ける：

• インストール。Linuxでは簡単ですが、Macでは難しく、Windowsでは非常に困難です。suアクセスの欠如およびその他の問題。

• これはSymPyの不可欠な部分です。つまり、sympyはそれなしでは機能しません（まったく）

• mpmathの仕事をすることができる他のパッケージはありません

• 「ユーザーとして、sympyをダウンロードしたとき、それが機能することを期待しています。」

それが私の特定の状況ですが、良い一般的な答えを提供する答えも受け入れます。

さらに別の答えですが、他のものもすべて良い答えですが、私が最も重要であると考えるもの（私個人の意見のみ）です。

libを個別にパッケージ化すると、アプリケーションを更新せずにlibを更新できます。libにバグがあるとすると、libを更新するだけでなく、アプリケーション全体を更新する必要があります。つまり、アプリケーションがlibのために、コードが変更されていなくてもバージョンバンプが必要になるということです。

あなたが言及した利点（セキュリティ、パッケージ、機能）に加えて、私はさらにいくつか考えることができます：

• 別のプログラムに役立つ機能を見つける人は、それを分割する作業を行う必要はありません。それは、機能がプロジェクトに最初からライブラリの形で存在するかどうかさえ知っている場合です。これは、プロジェクトが十分にモジュール化されているかどうかに依存します。

• これが他のプロジェクトに役立つ場合、これは一般的にディスク使用のサイズを減らします（例えば、コードの1つのコピーのみ）。

• これにより、コードの品質が向上し、いくつかの（非常に必要な）リファクタリングが必要になります。上記の最初のポイントと同様に、これもコードの品質に依存します。

• ライブラリーのユーザー数を増やすと（ライブラリーが分割されている場合）、ライブラリーがより汎用的になり、品質も向上する可能性があります。

利点は明らかですが、導入の容易さは、ライブラリをプログラムと一緒に出荷する場合の主要な議論のようです。

バンドリングに対するもう少しの議論があります：

• Linuxでは、ライブラリがその依存関係で適切に機能することを確認するのは、ディストリビューションのメンテナの仕事です。ほとんどのユーザーは、ディストリビューションのパッケージマネージャーを使用してライブラリをダウンロードします。トランクを使用している人は通常、とにかくライブラリの設定に時間を費やすことを気にしません。

• WindowsとMac OSでは、手動でライブラリをインストールするのが面倒なため、pipのようなPythonパッケージマネージャーが通常使用されます。

• Google App Engineへのハードデプロイについても議論がありますが、すべてのWebフレームワークがその上で実行されるわけではありません。多くは移植を必要とすることさえあり、ライブラリのディスク容量は限られています。結局それはWebアプリケーションのホスティングです！Webアプリケーションがシンボリック数学を使用することはほとんどありません。

• 依存関係が利用できない場合、またはバージョンが間違っている場合に、クリーンなエラーメッセージが表示されるのを防ぐ人はいません。

• プログラムはそれ自体が自分より賢いと考えると、人々はしばしばそれを嫌います。ユーザーが自分のシステムを管理できるようにします。

適切なパッケージインストーラのウィンドウにバンドルされていない処理する方法には、図書館の存在のPREINSTテストを持っているだろう、それはあなたがパッケージインストーラソフトウェアに含まれていることをライブラリパッケージからインストールするために提供するために存在しない場合は。Windowsポートを持つほとんどのGTKアプリは、これらの方針に沿って何かを行うと確信しています。

1つのサイズですべてに対応する必要はありません。

ソースディストリビューションの場合、バンドルすると、多くのディストリビューション（少なくともDebianとFedoraの遺産）のパッケージャは、バンドルを無効化または削除するために追加の作業を行う必要があります。これらのプラットフォームのパッケージポリシーは、バンドルを禁止するか、少なくとも強く阻止するためです。したがって、バンドルすることで、ほとんどメリットのないダウンストリーム用の作業が増えます。その議論はいくらか重みがありますか？

バイナリ配布（提供する場合）はどちらの方法でもかまいません。それらはダウンストリームで使用されないため、バンドルはおそらくそれらにとって意味があります。

しかし、WindowsインストーラーとMacインストーラーの反対の決定とバンドルを行えない理由はありません。

バンドルと依存の違いは、パッケージングの世界では古い議論です。このドキュメントでは、これら2つの考え方について説明しています。http：//www.aosabook.org/en/packaging.html