ライブラリフォルダーよりもパッケージマネージャーを好むのはなぜですか？

静的ライブラリフォルダーとパッケージマネージャーの長所と短所を考えると、ライブラリフォルダーの方が良いアプローチだと思います。

ライブラリフォルダーで表示される長所：

1. パッケージを管理するための外部ツールは必要ありません。
2. 構築にインターネット接続は必要ありません。
3. ビルドの高速化（パッケージチェックなし）。
4. よりシンプルな環境（必要な知識が少ない）。

パッケージマネージャーで見られる長所：

1. 複雑な依存関係ツリーを支援します（依存関係とそのすべての依存関係をダウンロードして管理できます）。
2. 利用可能な新しいバージョンがあるかどうかを確認するのに役立ちます。

業界は、今日構築されているほぼすべてについて、パッケージマネージャーパスに従うことを決定したようです。だから、私は何が欠けていますか？

他の答えに欠けている重要な点：

パッケージマネージャーを使用するということは、使用しているライブラリバージョンを示し、構成情報が実際に正しいことを確認する構成を持つことを意味します。

使用するライブラリとバージョンを知ることは、次の場合に非常に重要です。

• 重大なバグ/セキュリティホールのためにライブラリを更新する必要があります。
• または、発表されたセキュリティホールがあなたに影響を及ぼすかどうかを確認する必要があります。

さらに、実際に更新を行うとき、パッケージマネージャーは（通常）必要に応じて推移的な依存関係が更新されるようにします。

一方、libフォルダーの場合は、多数の（おそらくバイナリーで、おそらく変更された）ファイルがあり、それらがどこから来たのか、どのバージョンであるのかを推測する必要があります（または正しいかどうかわからないREADMEを信頼します） ）。

他のポイントに対処するには：

パッケージを管理するための外部ツールは必要ありません。

確かに、a）ソフトウェア開発者として、とにかく多くのツールをインストールする必要があるため、通常はもう1つは重要ではありません。b）通常、特定のフィールド（Maven / Gradle for Java、 JS / TypeScriptのnpmなど）、数十をインストールする必要があるわけではありません。

構築にインターネット接続は必要ありません。

私が知っているすべてのパッケージマネージャーは、必要な依存関係をダウンロードするとオフラインで動作します（プロジェクト自体をダウンロードした直後に発生する可能性があります）。

ビルドの高速化（パッケージチェックなし）。

おそらく真実ですが、オフラインパッケージのチェックにかなりの時間がかかる可能性は低いようです（一部のバージョン番号を比較するだけです）。オンラインチェックはしばらく時間がかかるかもしれませんが、必要であれば（それがデフォルトでも、オンになっている場合-例えばMavenは、リリースバージョンのアップデートをチェックしません）、それはオフにすることができます。

より単純な環境（知識が少なくて済みます）。

本当ですが、上で説明したように、libフォルダには知識も必要です。また、上記で説明したように、おそらくご存知のほんの一握りの異なるパッケージマネージャーでのみ作業します。

libフォルダーの長所は、小規模な開発から大規模な作業に移行するとすぐに消えます。

たとえば、外部ツールを必要としない「メリット」は、依存関係を手動で管理するために必要な作業に勝るので、ツールは（世界の複数の意味で）あなたになります。

パッケージマネージャーにインターネット接続は必要ありません。ローカルリポジトリを使用できます。

ビルドの高速化は正しいかもしれませんが、パッケージマネージャーを使用するかどうかを決定する必要があるものはほとんどありません。結局のところ、違いの大きさについて話しているのではなく、これも設定に依存します。パッケージマネージャーを使用すると、スロービルドを簡単に作成できますが、これは基本的に妨害行為です。

より単純な環境（必要な知識は少ない）？繰り返しますが、小規模開発では間違いなく可能性があります。使用されているいくつかのライブラリのそれぞれに至るまで、プロジェクトを完全に頭の中で保持できる場合があります。簡単なmakefile /その他のビルドスクリプトを追加すると、完全なパッケージが完成します。

しかし、それは環境を単純にするものではなく、単純な環境でのみ機能します。大規模な開発では、カスタムソリューションの代わりに標準のツールを使用することに満足します。結局のところ、それを一度学ぶ必要があるだけです（そして、パッケージマネージャーdu jourが新しいクールなものに置き換えられたら、それも学ぶ必要があります）。

パッケージマネージャーの多くの利点がありません。

1. パッケージマネージャを使用すると、大きな（数メガバイト以上の）バイナリをソース管理にチェックインすることを回避できます。そうすることは、多くのソース管理ツールにとって忌み嫌われるものであり、普及しているgitはその1つです。開発者がCocoaPodsをチェックインしていたため、数か月前にBit Bucketのサイズ制限に達するリポジトリがありました。すべてのlibバイナリをチェックインしていた（そしてNuGetを使用していなかった）ため、SVNから移行したとき、別のプロジェクトがすでにそこにありました。パッケージマネージャーは各開発者のパッケージをその場でダウンロードするため、これらのバイナリをチェックインする必要がなくなります。
2. 互換性のないファイル/ライブラリの混在を防ぎます。アップグレード中に誰かがライブラリのファイルを適切に削除しない場合、フォルダにはライブラリファイルの混合バージョンを含めることができます。フォルダ内のバイナリの半分がアップグレードされ、非常に奇妙なバグが発生するケースを見てきました。（クラッシュすらしませんでした！）問題を解明するのに、文字通り数ヶ月（人時間ではなく、全体的な時間）かかりました。パッケージマネージャーにフォルダー全体を制御させることにより、混合バージョンを取得できません。一貫性を確保します。また、自動的にすべてを一緒に更新したり、必要に応じて異なるバージョンをインストールしたり、互換性のないバージョンのライブラリを使用しようとしたときに警告やエラーを投げたりすることで、互換性のない依存関係を使用することをはるかに困難にします。
3. ライブラリを管理するための共有規約を確立します。新しい開発者がプロ​​ジェクト、チーム、会社などに来たとき、彼らはパッケージマネージャーの規約を知っているでしょう。これは、ライブラリがコードベースでどのように管理されているかの詳細を把握するのに時間を無駄にする必要がないことを意味します。
4. リポジトリに属さない独自の依存関係とファイルをバージョニングおよび配布する標準的な方法を提供します。私は自分のアプリケーションが必要とするいくつかの大きな静的データファイルのためにそれらを個人的に利用しているので、バイナリコード以外のバージョン管理にもうまく機能します。
5. 一部のパッケージマネージャーは、インストール中に追加機能を提供します。NuGetは、csprojファイルに依存関係とコンテンツファイルを追加し、構成ファイルに構成要素を追加することもできます。
6. パッケージリストファイルには、ライブラリのバージョンが1か所にまとめられています。DLLを右クリックしてバージョン番号を見て、使用しているライブラリのバージョンを把握する必要はありません。Pythonでは、ライブラリの作成者がpyファイルにバージョン番号を含めていない可能性があるため、それらからライブラリのバージョンを特定することさえできない場合があります。
7. マシン全体の依存関係のインストールを阻止します。パッケージマネージャーは、グローバルインストーラーなしで依存関係をインストールする従来の方法を提供します。オプションがlibフォルダーおよびグローバルインストールの場合、多くのライブラリ開発者は、自分でセットアップする必要があるダウンロード可能なバイナリではなく、グローバルインストールとしてライブラリをプライマリに提供することを選択します。（MSの歴史はこれを示しています。Linuxの多くのライブラリにも当てはまります。）これは実際に複数のプロジェクトを管理することを難しくします。 dir。
8. 彼らは、ホスティングと配信を一元化する傾向があります。そのランダムライブラリのWebサイトに依存する必要はなくなりました。彼らが廃業したとしても、成功したパッケージマネージャーのサイトにはすべてのバージョンがアップロードされています。開発者は、新しいライブラリをダウンロードするためだけに多くのWebサイトを探し回る必要もありません。彼らは最初に見て、さらにはさまざまなオプションを参照するための場所を持っています。また、アドホックWebサイトのすべてのコピーを手動でホストするよりも、標準的な方法で編成されたパッケージをミラーリングする方が簡単です。

また、「利益」の価値を誇張しています。

1. パッケージを管理するための外部ツールは必要ありません。

   何に「外部」？NuGet実行可能ファイルをリポジトリにチェックインします。それは小さいので、他のバイナリをチェックインする必要がないので、チェックインしても大丈夫だと思う唯一のバイナリです。

   pipは、現在デフォルトでPythonにバンドルされており、破損や後方互換性のない変更が非常にまれなので、この点で問題を引き起こすことはありません。とにかく、プロジェクトの外部にPythonをインストールせずにPythonコードを開発するつもりはありません。

   広く採用されるまでに、パッケージマネージャーは非常に安定する傾向があります。ほとんどのプロジェクトでは、何らかのグローバルにインストールされたツールなしで逃げることはできません。また、単一のパッケージマネージャーは非常に軽量な要件です。通常、言語ランタイムをインストールするよりも面倒ではありません。

2. 構築にインターネット接続は必要ありません。

   ネットワークに接続せずにデータベースに接続できません。データベースがAmazonでホストされている場合、とにかく完全なインターネット接続が必要です。ソース管理を通じて変更をプッシュおよびプルするには、インターネット接続が必要です。ビルドサーバーは、何らかのネットワーク接続なしにビルドするコードもチェックアウトできません。電子メールがないと、電子メールを送受信できません。ライブラリがないと、ライブラリをダウンロードしてlibフォルダに入れることはできません！インターネットに接続せずに永続的に開発することは事実上前代未聞です。まれに、必要な場合には、パッケージマネージャーが使用できる場所にパッケージをダウンロードすることでこれに対処できます。（NuGetとpipは、単純なフォルダーまたはネットワークドライブから取得できることを非常に喜んでいます。他のほとんどのユーザーも同様にできると思います。）

3. ビルドの高速化（パッケージチェックなし）。

   自動ビルド中に30秒、ローカル開発ビルド中に5秒は、上記で説明した利点とのトレードオフです。これらは些細な時間枠であり、通常は利点が解決する問題と比較して考慮する価値さえありません。

4. より単純な環境（知識が少なくて済みます）。

   パッケージ管理のための一つのツールは何もライブラリ管理のためには、とにかく、本当に公平な比較ではありません。ツールがなければ、プロジェクトが使用しているカスタムプロセスを学習する必要がありますライブラリを管理します。これは、既存の知識が新しいプロジェクトに適用されるかどうかがわからないことを意味します。誰かが思いついたホッジポッドアプローチに対処するか、自分で作成する必要があります。それはすべてのライブラリを含むディレクトリかもしれませんし、もっと奇妙なものかもしれません。ライブラリのチェックインを回避するために、誰かがそれらをすべてネットワークドライブに配置し、唯一のバージョンインジケータはフォルダ名です。それともグローバルインストールはどうですか？比較すると、パッケージマネージャーは、遭遇するほとんどのプロジェクトに適用されるクリーンな規則を提供します。

共通のテーマは、プロジェクト内だけでなく、プロジェクト全体で一貫性、ドキュメント、および機能を提供することです。これにより、全員の生活が簡素化されます。

最近、製品を手動でダウンロードしたライブラリの使用からNugetによる自動パッケージ管理に変換したことから、パッケージマネージャーを使用することには大きなメリットがあると言えます。

当社の製品は27のC＃プロジェクトに実装されていますが、今日の標準では比較的小規模です。サードパーティの依存関係の一部には、多数のアセンブリがあります。

Nugetの前に、すべての依存関係を最新バージョンに更新するには、次の手順を実行する必要があります。

1. 更新されたすべてのライブラリを入手できる場所を追跡する
2. それらをダウンロードして解凍/インストールします
3. ソース管理に新しいバージョンを追加します
4. プロジェクトのすべての参照を手動で調べて、新しいアセンブリを指すように更新します

27のプロジェクトと多数の依存関係アセンブリがあるため、このプロセスは非常にエラーが発生しやすく、数時間かかる可能性がありました。

Nugetの使用に更新したので、1つのコマンドですべて完了しました。

パッケージを管理するための外部ツールは不要

それは一種の非ポイントですか？パッケージマネージャーを使用する場合、libフォルダーは必要ありません。パッケージを自分で管理する必要もありません。

構築にインターネット接続は必要ありません

現在、開発中にインターネットに接続できないことはややまれですが（転送中を除く）、適切なパッケージマネージャーは、アプリケーションをビルドするために最新バージョンを持っている必要はありません。文句を言うかもしれませんが、すでにインストールされているバージョンでビルドしない理由はありません

ビルドの高速化（パッケージチェックなし）

それはかなり限界的なスピ​​ードブーストですが、間違いなくそのためのポイントを作ることができます。

より単純な環境（必要な知識が少ない）

最近のほとんどのパッケージマネージャーは非常に単純なので、これらを実行してそれらを回避しようとする価値はほとんどありません。必要に応じて、ビジュアルクライアントもあります。彼らは実際に起こっている多くの小作地を隠しています。

パッケージマネージャーを使用すると、これらのパッケージを異なるプロジェクト間で共有することもできます。5つのプロジェクトで同じバージョンのBoostを使用している場合、プロジェクトごとにこれを複製する必要はありません。これは特に、複雑な依存関係ツリーについて当てはまります。

libフォルダーを使用すると、そのプロジェクトのパッケージのみを管理できますが、パッケージマネージャーを使用すると、単一のツールで開発環境全体でこれを実行できます。

それはちょうど間の差である使用してライブラリ（libディレクトリ）を、そして維持し、それらを使用してメタ情報 （パッケージマネージャ）。このようなメタ情報は、バージョン番号、ライブラリ間の（推移的な）依存関係などに関するものです。

DLLの地獄、ライブラリの互換性、Javaモジュールシステム、OSGiなどの議論は、少なくとも、何らかの形の依存関係管理があることを十分に納得させるはずです。

• ライブラリのバージョンと依存関係の問題は時間の浪費になる可能性があります。

また、共有（ローカル）リポジトリの利点があるため、いくつかのプロジェクトはインポートされたライブラリのコピーを保持する必要がありません。20個のサブモジュールを持つプロジェクトがある場合、それらのモジュールの一部には40の奇数の依存関係があります。

• より多くの構造
• ライブラリのさらなるトリミング
• 図書館に関するアドホックな人間の決定はありません

libフォルダーが必要になる場合があります。たとえば、廃止されたライブラリー（そのバージョンは保守/使用不可になっている）、ローカルに変更されたバージョンのライブラリー、...

しかし、他のすべてについては、パッケージマネージャーの役​​割を引き受ける開発者のようなものです。

• 開発者はライブラリをダウンロードする必要があります（インターネットが必要です）
• 開発者は新しいリリースを手動で確認する必要があります
• ...

そして、私見、それはあなたが外部ツールの使用法について学ぶ必要があるので、より少ない知識が必要です。

他の質問でカバーされない別の問題があります：共有の深さ。

たとえば、同じライブラリを構築する 2つのパッケージがあるとします。最良の場合、競合はありませんが、同じHDD / SSDスペースが2回使用されます。最悪の場合、バージョンなどのさまざまな競合が発生します。

パッケージマネージャーを使用する場合、ライブラリーは（バージョンごとに）1回だけインストールされ、既にライブラリーへのパスが提供されます。

PS：もちろん、あなたはこのプロを得るために動的リンケージ（またはあなたの言語の同様の機能）を必要とします。

90年代のUnixおよびWindowsシステムで共有ライブラリが進歩の項目と見なされた主な理由の1つは、同じライブラリセットを使用する複数のプログラムがロードされたときにRAM使用量を削減できることでした。コードスペースは、ライブラリとそのライブラリのバージョンごとに1回だけ割り当てる必要があり、インスタンスごとのメモリ使用量は、静的変数のみです。

多くのオペレーティングシステムは、unix mmap（）apiなどのメカニズムに依存する方法で共有ライブラリを実装します。これは、ライブラリが正確に同じバージョンであるだけでなく、実際にはまったく同じFILEである必要があることを意味します。これは、独自のライブラリセットを出荷するプログラムで最大限に活用することは不可能です。

メモリがはるかに安価であり、ライブラリバージョンが90年代よりも多様である必要があることを考えると、この議論は今日ほど重要ではありません。