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

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

私はこれが一般的になぜ良いのか知っています。より速いセキュリティ修正、より簡単なパッケージング、より多くの機能です。しかし、私はいくつかの同僚に私たちのプログラムと一緒にライブラリをバンドルする必要がないことを説得しようとしています。このライブラリなしでは動作しませんが、ライブラリはしばらく安定しており、近い将来でも安定しています。分け合わない理由がないと思います。

彼らを説得するためにどのような主張を使用できますか?


私の具体的な状況は次のとおりです。努力中です。シンボル、シンボル数学のためのオープンソースPythonライブラリ。コア部品の一つは数学、多精度浮動小数点演算のためのライブラリです。 SymPyはmpmathなしでは動作せず、選択肢はありません。そのため、最初からSymPyにバンドルされていました(通常、新しいバージョンをインポートするたびに修正する必要があるマイナーな非互換性があると聞きました)。また、mpmath開発者がSymPy開発に参加したことにも注意する必要があります。今mpmathのバインド解除に関する質問があります。すべて読むことができます。ここ

そこで議論を要約すると、次のようになります。

バインド解除:

  • Python 3に移植する方が簡単です(IMHO、小さな引数)

  • より簡単な包装の配布

  • ユーザーに高速(セキュリティ)機能の更新を提供

  • 「パッケージングと依存関係の処理は難しい問題でしたが、解決されました。確かに私たちが直接行う必要がある分野ではありません。」

継続バンドル:

  • インストールする。 Linuxでは簡単で、Macではより難しく、Windowsでは非常に難しいです。 su アクセス権の不足などの問題。

  • これはSymPyの不可欠な部分です。つまり、SymPyはSymPyなしでは(まったく)動作できません。

  • 持ついいえmpmath操作を完了できるその他のパッケージ

  • 「ユーザーとしてSympyをダウンロードするときに機能したいです。」


これは私の特定の状況ですが、素晴らしいと一般的な答えを提供する答えを受け入れます。

答え1

あなたが言及した利点(セキュリティ、パッケージング、機能)に加えて、次のようなより多くの利点があると思います。

  • 誰かが他のプログラムでその機能が役に立つと思っている場合は、その機能を分離する作業を行う必要はありません。つまり、その機能がプロジェクトにライブラリとして存在するかどうかを最初に知っている場合です。プロジェクトが十分にモジュール化されているかどうかは、どれだけうまく設計されたかによって異なります。

  • これは通常、他のプロジェクトに役立つ場合(たとえば、1つのコードコピー)、ディスク使用量のサイズを減らします。

  • これにより、コードの品質が向上し、いくつかの(非常に必要な)リファクタリングを実行する必要があります。上記の最初のものと同様に、これもコードの品質によって異なります。

  • ライブラリーのユーザー数を増やすと(分離されている場合)、ライブラリーはさらに多様化し、品質も向上する可能性があります。

答え2

別の答えがありますが、他の答えもすべて良い答えですが、これが最も重要な答えだと思います(個人的な意見だけです)。

libを別々にパッケージ化すると、アプリケーションを更新することなくlibを更新できます。ライブラリにバグがあると仮定すると、ライブラリのみを更新するのではなく、アプリケーション全体を更新する必要があります。これは、アプリケーションのバージョンアップグレードが必要ですが、ライブラリのためにコードが変更されていないことを意味します。

答え3

利点は明らかですが、展開の容易さはあなたの場合、プログラムと共にライブラリをリリースする主な主張であるようです。

バンドルに反対するいくつかの追加の主張は次のとおりです。

  • Linuxでは、ライブラリとその依存関係が正しく機能していることを確認することがディストリビューションマネージャの使命です。それにもかかわらず、ほとんどのユーザーはディストリビューションのパッケージマネージャを使用してライブラリをダウンロードします。トランクを使用している人は通常、ライブラリの構築に時間を費やすことを気にしません。

  • WindowsとMac OSでは、ライブラリを手動でインストールするのは面倒なので、pipなどのPythonパッケージマネージャを頻繁に使用します。

  • Google App Engineへのハード展開に関する議論もありますが、すべてのWebフレームワークがGoogle App Engineで実行されるわけではありません。多くの場合、移植が必要であり、ライブラリにはディスク容量が限られており、これは最終的にWebアプリケーションホスティングです! Webアプリケーションはシンボル数学を使用しません。

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

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

答え4

1つのサイズが必ずしもすべてに適しているわけではありません。

ソースディストリビューションの場合、バンドルを実行する場合、多くのディストリビューション(少なくともDebianおよびFedoraレガシー)のパッケージャは、これらのプラットフォームのパッケージポリシーがバンドルを禁止または少なくとも強力に防止するため、バンドルを無効または削除するための追加の作業を実行する必要があります。 。したがって、バンドルを使用するとほとんど利益がありませんが、ダウンストリームでより多くのタスクが作成されます。この主張はどのくらいの重量を置くことができますか?

バイナリディストリビューション(提供する場合)はどちらの方向にでも行くことができます。ダウンストリームとして使用されないため、バンドルが適している可能性があります。

しかし、逆に、WindowsとMacの両方のインストーラのバンドルを提供できない理由はありません。

関連情報