ライブラリフォルダーよりもパッケージマネージャーを好むのはなぜですか？
静的ライブラリフォルダーとパッケージマネージャーの長所と短所を考えると、ライブラリフォルダーの方が良いアプローチだと思います。
私がライブラリフォルダーで見る長所：
- パッケージを管理するための外部ツールは必要ありません。
- 構築にインターネット接続は必要ありません。
- より高速なビルド（パッケージチェックなし）。
- よりシンプルな環境（必要な知識が少ない）。
私がパッケージマネージャーで見る長所：
- 複雑な依存関係ツリーを支援します（依存関係とそのすべての依存関係をダウンロードして管理できます）。
- 利用可能な新しいバージョンがあるかどうかの確認に役立ちます。
業界は、今日構築されたほとんどすべてのパッケージマネージャーパスに従うことを決定したようです。それで、私は何が欠けていますか？
他の回答に欠けている重要なポイント：
パッケージマネージャを使用するということは、使用しているライブラリのバージョンを示し、構成情報が実際に正しいことを確認する構成を持つことを意味します。
使用するライブラリとバージョンを知ることは、次の場合に非常に重要です。
- 重大なバグ/セキュリティホールのためにライブラリを更新する必要がある;
- または、発表されたセキュリティホールがあなたに影響を与えるかどうかを確認する必要があるだけです。
さらに、実際に更新を行う場合、パッケージマネージャーは（通常）推移的な依存関係が必要に応じて更新されるようにします。
libフォルダーの場合、（バイナリであり、変更されている可能性がある）ファイルの束があり、それらがどこから来たのか、どのバージョンなのかを推測する必要があります（または、READMEを信頼します。正しい場合とそうでない場合があります）。
他のポイントに対処するには：
パッケージを管理するための外部ツールは必要ありません。
確かに、しかしa）ソフトウェア開発者として、とにかく大量のツールをインストールする必要があるため、通常はもう1つは問題ではありません。b）通常、特定のフィールド（Maven/Gradle for Java、 JS/TypeScriptなどのnpm）なので、何十ものインストールする必要はありません。
構築にインターネット接続は必要ありません。
私が知っているすべてのパッケージマネージャーは、必要な依存関係をダウンロードするとオフラインで動作します（プロジェクト自体をダウンロードした直後に発生する可能性があります）。
より高速なビルド（パッケージチェックなし）。
おそらく正しいですが、オフラインパッケージのチェックにかなりの時間がかかる可能性は低いようです（バージョン番号の比較だけです）。 onlineチェックには時間がかかる場合がありますが、必要に応じてオフにすることができます（デフォルトでオンになっている場合-Mavenは、たとえばリリースバージョンのアップデートをチェックしません）。
よりシンプルな環境（必要な知識が少ない）。
正しいですが、上記で説明したように、libフォルダーにも知識が必要です。また、上で説明したように、おそらくご存じのように、少数の異なるパッケージマネージャーのみを操作することになります。
小規模開発から大規模な作業に移行すると、libフォルダーの長所がすぐに消えます。
たとえば、外部ツールを必要としない "メリット"は、依存関係を手動で管理するために必要な作業に負けてしまうため、ツールは（世界の複数の意味で）あなたになります。
パッケージマネージャーにインターネット接続は必要ありません。ローカルリポジトリを使用できます。
より高速なビルドは本当かもしれませんが、パッケージマネージャーを使用するかどうかを決定する必要があるものではありません。結局のところ、違いの大きさについて話しているのではなく、これも構成によって異なります。パッケージマネージャーを使用すると、遅いビルドを簡単に作成できますが、それは基本的に妨害行為です。
よりシンプルな環境（必要な知識が少ない）？繰り返しますが、小規模な開発では間違いなく可能性があります。使用されているいくつかのライブラリのそれぞれに至るまで、プロジェクトを完全に頭に抱えることができるかもしれません。単純なmakefile /その他のビルドスクリプトを追加すると、完全なパッケージが得られます。
しかし、それはmake環境を単純化せず、単純な環境でのみ機能します。大規模な開発では、カスタムソリューションの代わりに標準のツールを使用していることに満足するでしょう。結局のところ、それを学ぶ必要があるのは1回だけです（そして、パッケージマネージャーデュジャールが新しいクールなものに置き換えられた場合も、それを学ぶ必要があります）。
パッケージマネージャーの利点のmanyがありません。
- パッケージマネージャーを使用すると、大きな（数メガバイト以上の）バイナリをソース管理にチェックインすることを回避できます。そうすることで、多くのソース管理ツールに悪影響が及びます。開発者がCocoaPodsをチェックインしていたため、リポジトリは数か月前にBit Bucketのサイズ制限に達しました。すべてのlibバイナリをチェックインしていたため（そしてNuGetを使用していなかったため）、SVNから移行したときに別のプロジェクトがすでに途中にありました。パッケージマネージャーは、開発者ごとにその場でパッケージをダウンロードするため、これらのバイナリをチェックインする必要がなくなります。
- 互換性のないファイル/ライブラリの混在を防止します。アップグレード中に誰かがライブラリを適切に消去しない場合、フォルダにライブラリのファイルの混在バージョンを含めることができます。フォルダー内のバイナリの半分がアップグレードされてvery奇妙なバグが発生するケースを見ました。 （クラッシュすらしませんでした！）問題を解決するのに、文字通り数ヶ月（人時間ではなく、全体の時間だけ）かかりました。パッケージマネージャーにフォルダー全体を制御させると、バージョンが混在することはありません。一貫性を確保します。それらはまた、互換性のないdependenciesを使用することをはるかに困難にします。すべてを一緒に自動的に更新するか、必要に応じて異なるバージョンをインストールするか、または互換性のないバージョンのライブラリを使用しようとすると警告またはエラーがスローされるだけです。
- 彼らは共有conventionライブラリを管理するために確立します。新しい開発者がプロジェクト、チーム、会社などに出くわすとき、彼らはパッケージマネージャーの規則を知っている可能性が高いです。これは、ライブラリがコードベースでどのように管理されているかの詳細を把握するために時間を浪費する必要がないことを意味します。
- リポジトリに属さない独自の依存関係とファイルをバージョン管理および配布するための標準的な方法を提供します。アプリケーションが必要とするいくつかの大きな静的データファイルに個人的に利用したので、機能しますバイナリコード以外のバージョン管理にも適しています。
- 一部のパッケージマネージャーは、インストール中に追加機能を提供します。 NuGetは依存関係とコンテンツファイルをcsprojファイルに追加し、構成要素を構成ファイルに追加することもできます。
- これらのパッケージリストファイルには、ライブラリのバージョンが1か所にまとめられています。 DLLを右クリックしてバージョン番号を確認する必要はありません。私が使用しているライブラリのバージョン。 Pythonでは、ライブラリの作成者がpyファイルにバージョン番号を含めていなかった可能性があるため、ライブラリのバージョンをそれらから区別できない場合もあります。
- 依存関係のマシン全体のインストールを推奨しません。パッケージマネージャーは、依存関係をインストールする従来の方法を提供しますグローバルインストーラーなし。オプションがlibフォルダーとグローバルインストールの場合、多くのライブラリ開発者は、自分でセットアップする必要があるダウンロード可能なバイナリとしてではなく、グローバルインストールとしてライブラリをプライマリに提供することを選択します。 （MSの履歴はこれを示しています。Linuxの多くのライブラリの場合も同様です。）バージョンが競合しているプロジェクトがあり、一部の開発者は独自のlibよりも一見単純なグローバルインストールを選択するため、実際には複数のプロジェクトの管理がより困難になります。 dir。
- ホスティングと配布を一元化する傾向があります。ランダムライブラリのWebサイトに依存する必要がなくなりました。彼らが廃業した場合でも、成功したパッケージマネージャーのサイトには、すべてのバージョンがアップロードされています。開発者は、新しいライブラリをダウンロードするためだけに多くのWebサイトを探す必要もありません。彼らは最初に見て、異なるオプションを参照するための頼りになる場所を持っています。また、アドホックWebサイトからすべてのコピーを手動でホストするよりも、標準的な方法で編成されたパッケージをミラー化する方が簡単です。
また、「利益」の価値を過大評価しています。
パッケージを管理するための外部ツールは必要ありません。
「外部」って何？ NuGet実行可能ファイルをリポジトリにチェックインします。それは小さいので、他のバイナリをチェックインする必要がないことを意味するので、チェックインしても問題ないと感じる唯一のバイナリです。
現在、デフォルトでPythonにバンドルされているため、pipはこの問題を引き起こしません。互換性のない変更の互換性の破壊や破壊は非常にまれです。とにかく、プロジェクトの外部にPythonをインストールせずにPythonコードを開発することはありません。
パッケージマネージャーが広く採用されるまでに、パッケージマネージャーは非常に安定する傾向があります。 someほとんどのプロジェクトでグローバルにインストールされているツールなしでは逃れることはできません。単一のパッケージマネージャーはかなり軽量な要件です。通常、言語ランタイムをインストールするよりもそれほど面倒ではありません。
構築にインターネット接続は必要ありません。
ネットワークに接続しないとデータベースに接続できません。データベースがAmazonでホストされている場合は、とにかく完全なインターネット接続が必要です。ソース管理を通じて変更をプッシュおよびプルするには、インターネット接続が必要です。ビルドサーバーは、なんらかのネットワーク接続がないとビルドするコードをチェックアウトできません。 電子メールの送受信なしではできません。ライブラリをダウンロードして、ライブラリなしでlibフォルダーに配置することはできません！インターネットに接続せずに永続的に開発することは、ほとんど前代未聞です。必要なまれなケースでは、パッケージマネージャーが使用できる場所にパッケージをダウンロードすることでこれに対処できます。 （私はNuGetとpipが単純なフォルダーまたはネットワークドライブからプルすることを非常に喜んでいることを知っています。他のほとんどのユーザーも同様にできると思います。）
より高速なビルド（パッケージチェックなし）。
自動ビルド中に30秒、ローカル開発ビルド中に5秒は、上で概説した利点とのトレードオフです。これらはtrivialの時間枠であり、通常、メリットが解決する問題と比較して検討する価値さえありません。
よりシンプルな環境（必要な知識が少ない）。
とにかく、ライブラリ管理用のnothingに対するパッケージ管理用の1つのツールは、実際には公平な比較ではありません。ツールがなければ、ライブラリを管理するためにプロジェクトが使用しているカスタムプロセスを学習する必要があります。つまり、既存の知識が新しいプロジェクトに当てはまるかどうかは決してわかりません。誰かが思いついたホッジポッジアプローチに対処するか、独自のアプローチを作成する必要があります。それはすべてのライブラリを含むディレクトリかもしれませんし、もっと奇妙なものかもしれません。ライブラリのチェックインを回避するために、ライブラリをすべてネットワークドライブに配置し、バージョンインジケーターはフォルダー名のみです。それまたはグローバルインストールは本当に優れていますか？比較すると、パッケージマネージャーは、遭遇するほとんどのプロジェクトに適用される明確な規則を提供します。
共通のテーマは、プロジェクト内だけでなく、プロジェクト全体での一貫性、ドキュメント、機能を提供することです。これは皆の生活を簡素化します。
最近、手動でダウンロードしたライブラリの使用からNugetを使用した自動パッケージ管理に製品を変換したので、パッケージマネージャーを使用することには大きなメリットがあると言えます。
当社の製品は27のC＃プロジェクトに実装されており、今日の基準では比較的小規模です。サードパーティの依存関係の一部には、数十のアセンブリがあります。
Nuget以前は、すべての依存関係を最新バージョンに更新したい場合は、次のようにする必要があります。
- 更新されたライブラリをすべて入手できる場所を追跡する
- それらをダウンロードして解凍/インストールしてください
- 新しいバージョンをソース管理に追加する
- プロジェクトのすべての参照を手動で調べ、新しいアセンブリを指すように更新します。
27のプロジェクトと数十の依存関係アセンブリがあるため、このプロセスは非常にエラーが発生しやすく、数時間かかる可能性があります。
Nugetを使用するように更新したので、1つのコマンドですべて完了です。
パッケージを管理するための外部ツールは不要
それは一種の非ポイントですよね？パッケージマネージャーを使用する場合、libフォルダーは必要ありません。また、自分でパッケージを管理する必要もありません。
構築にインターネット接続は必要ありません
開発中にインターネットに接続できないことは少ししかありません（転送中を除いて）とはいえ、まともなパッケージマネージャーがアプリケーションをビルドするために最新バージョンを持っている必要はありません。文句を言うかもしれませんが、すでにインストールされているバージョンでビルドしない理由はありません
より高速なビルド（パッケージチェックなし）
これはかなり限界的なスピードブーストですが、間違いなくその点を指摘できます。
よりシンプルな環境（必要な知識が少ない）
最近のほとんどのパッケージマネージャーは非常に単純なので、これらを実行することで回避する価値はほとんどありません。必要に応じて、ビジュアルクライアントもあります。彼らは実際に起こっている多くの小作を隠しています。
パッケージマネージャを使用すると、異なるプロジェクト間でこれらのパッケージを共有することもできます。 5つのプロジェクトで同じバージョンのBoostを使用している場合、プロジェクトごとにこれを複製する必要はありません。これは、あなたが話す複雑な依存関係ツリーに特に当てはまります。
Libフォルダーを使用すると、そのプロジェクトのパッケージのみを管理できますが、パッケージマネージャーを使用すると、開発環境全体に対して単一のツールでこれを実行できます。
これは、usingライブラリ（libディレクトリ）と、それらを使用して、meta-information（package manager）を維持します。このようなメタ情報は、バージョン番号、ライブラリ間の（推移的な）依存関係などに関係します。
DLL地獄、ライブラリの互換性、Javaモジュールシステム、OSGiなど）の議論は、少なくとも何らかの形の依存関係管理の価値があることを十分に納得させるはずです。
- ライブラリのバージョンと依存関係の問題は時間の浪費になる可能性があります。
また、共有（ローカル）リポジトリの利点があるため、いくつかのプロジェクトはインポートされたライブラリのコピーを維持する必要がありません。 20のサブモジュールを持つプロジェクトがある場合、それらのモジュールの一部には40の奇数の依存関係があります。
- より多くの構造
- ライブラリのトリミングを増やす
- 図書館に関する特別な人間の決定はありません
Libフォルダーが必要になる場合があります。たとえば、廃止されたライブラリー（そのバージョンの保守/利用不可）、ローカルで変更されたライブラリーなどを扱う場合などです。
しかし、それ以外のすべては、パッケージマネージャーの役割を引き受ける開発者のようなものです。
- 開発者はライブラリをダウンロードする必要があります（インターネットが必要です）
- 開発者は手動で新しいリリースを確認する必要があります
- ...
そして私見、外部ツールの使用法について学ぶ必要があるので、必要な知識は少ないですが、ライブラリー（つまり、依存関係）については少ないです。
他の質問ではカバーされていない別の問題があります。
たとえば、2つのパッケージbuildingが同じライブラリであるとします。最良の場合、競合は発生しませんが、同じHDD/SSDスペースが2回使用されます。最悪の場合、バージョンなど、さまざまな競合が発生します。
パッケージマネージャーを使用する場合、ライブラリは（バージョンごとに）1回だけインストールされ、すでにそのパスが提供されます。
PS：もちろん、あなたはこのプロを得るために動的リンケージ（またはあなたの言語で同様の関数）が必要です。