Warum einen Paketmanager einem Bibliotheksordner vorziehen?

Wenn ich über die Vor- und Nachteile eines statischen Bibliotheksordners und eines Paketmanagers nachdenke, halte ich den Bibliotheksordner für einen besseren Ansatz.

Vorteile, die ich mit einem Bibliotheksordner sehe:

1. Es ist kein externes Tool zum Verwalten von Paketen erforderlich.
2. Zum Aufbau ist keine Internetverbindung erforderlich.
3. Schnellere Erstellung (keine Paketprüfung).
4. Einfachere Umgebung (weniger Kenntnisse erforderlich).

Vorteile, die ich mit einem Paketmanager sehe:

1. Hilft bei komplexen Abhängigkeitsbäumen (und das Herunterladen einer Abhängigkeit mit all ihren Abhängigkeiten kann verwaltet werden).
2. Hilft bei der Überprüfung, ob eine neue Version verfügbar ist.

Anscheinend hat sich die Branche dazu entschlossen, für fast alles, was heute gebaut wird, dem Paketmanager-Pfad zu folgen. Also, was fehle ich?

Ein wichtiger Punkt, der in den anderen Antworten fehlt:

Wenn Sie einen Paketmanager verwenden, müssen Sie eine Konfiguration haben, die angibt, welche Bibliotheksversionen Sie verwenden, und die sicherstellt, dass die Konfigurationsinformationen tatsächlich korrekt sind.

Es ist sehr wichtig zu wissen, welche Bibliotheken Sie verwenden und welche Version Sie verwenden, wenn Sie:

• muss eine Bibliothek aufgrund eines kritischen Fehlers / einer Sicherheitslücke aktualisieren;
• oder Sie müssen nur überprüfen, ob eine gemeldete Sicherheitslücke Sie betrifft.

Wenn Sie tatsächlich aktualisieren, stellt der Paketmanager (normalerweise) sicher, dass alle transitiven Abhängigkeiten nach Bedarf aktualisiert werden.

Während bei einem libOrdner nur eine Reihe von (möglicherweise binären und möglicherweise geänderten) Dateien vorhanden sind, müssen Sie erraten, woher sie stammen und welche Version sie haben (oder einer README-Datei vertrauen, die möglicherweise korrekt ist oder nicht ).

Um Ihre anderen Punkte anzusprechen:

Kein externes Tool zum Verwalten von Paketen erforderlich.

Richtig, aber a) als Softwareentwickler müssen Sie ohnehin jede Menge Tools installieren, damit eine weitere Rolle keine Rolle spielt, und b) normalerweise gibt es nur einen oder mehrere Paketmanager in einem bestimmten Bereich (Maven / Gradle für Java, npm für JS / TypeScript usw.), daher müssen Sie nicht Dutzende davon installieren.

Zum Aufbau ist keine Internetverbindung erforderlich.

Alle Paketmanager, die ich kenne, arbeiten offline, sobald sie die erforderlichen Abhängigkeiten heruntergeladen haben (was direkt nach dem Herunterladen des Projekts geschehen kann).

Schnellere Erstellung (keine Paketprüfung).

Wahrscheinlich wahr, aber es scheint unwahrscheinlich, dass die Offline-Paketprüfung viel Zeit in Anspruch nimmt (es werden nur einige Versionsnummern verglichen). Eine Online- Prüfung kann eine Weile dauern, kann aber auf Wunsch deaktiviert werden (wenn sie sogar standardmäßig aktiviert ist - Maven sucht beispielsweise nie nach Updates für Release-Versionen).

Einfachere Umgebungen (weniger Kenntnisse erforderlich).

Richtig, aber wie oben erläutert, liberfordert ein Ordner auch Kenntnisse. Wie oben erklärt, werden Sie wahrscheinlich nur mit einer Handvoll verschiedener Paketmanager arbeiten, die Sie bereits kennen.

Die Vorteile des Ordners lib verschwinden schnell, wenn Sie von der kleinen Entwicklung zur größeren Arbeit übergehen.

Zum Beispiel wird der "Vorteil", kein externes Tool zu benötigen, durch die Arbeit übertroffen, die erforderlich ist, um Ihre Abhängigkeiten manuell zu verwalten, sodass Sie das Tool sein werden (in mehr als einem Sinne der Welt).

Sie benötigen keine Internetverbindung für einen Paketmanager. Sie können lokale Repositorys verwenden.

Ein schnellerer Build mag stimmen, aber es ist kaum etwas, das entscheiden sollte, ob ein Paketmanager verwendet werden soll oder nicht. Wir sprechen schließlich nicht über Größenunterschiede, und dies hängt auch von Ihrer Konfiguration ab. Sie können mit einem Paketmanager leicht einen langsamen Build erstellen, aber das ist im Grunde genommen Sabotage.

Einfachere Umgebungen (weniger Kenntnisse erforderlich)? Auch hier ist in kleinem Maßstab eine Entwicklung durchaus möglich. Möglicherweise können Sie das Projekt bis auf die wenigen verwendeten Bibliotheken vollständig im Kopf behalten. Fügen Sie ein einfaches Makefile oder ein anderes Build-Skript hinzu, und Sie haben ein vollständiges Paket.

Dies vereinfacht jedoch nicht die Umgebung, sondern funktioniert nur in einfachen Umgebungen. Bei der Entwicklung in größerem Maßstab werden Sie froh sein, dass Sie Standardwerkzeuge anstelle von kundenspezifischen Lösungen verwenden. Schließlich muss man es nur einmal lernen (und wenn der Paketmanager du jour durch das neue coole Ding ersetzt wird, muss man das auch lernen).

Ihnen fehlen viele Vorteile von Paketmanagern.

1. Mit Paketmanagern können Sie vermeiden, dass große (mehrere Megabyte oder mehr) Binärdateien in die Quellcodeverwaltung eingecheckt werden. Dies ist ein Gräuel für viele Tools zur Quellcodeverwaltung. Wir hatten vor ein paar Monaten ein Repository, das die Größenbeschränkungen von Bit Bucket überschritt, weil Entwickler CocoaPods eincheckten. Ein anderes Projekt befand sich bereits auf halber Strecke, als wir von SVN migrierten, weil wir alle unsere Lib-Binärdateien eingecheckt hatten (und NuGet nicht verwendet hatten). Da Paketmanager Pakete für jeden Entwickler im laufenden Betrieb herunterladen, müssen diese Binärdateien nicht mehr eingecheckt werden.
2. Sie verhindern das Mischen inkompatibler Dateien / Bibliotheken. Ordner können gemischte Versionen der Bibliotheksdateien enthalten, wenn diese während eines Upgrades nicht ordnungsgemäß bereinigt werden. Ich habe einen Fall gesehen, in dem die Hälfte der Binärdateien im Ordner aktualisiert wurde, was zu sehr seltsamen Fehlern führte. (Es ist nicht einmal abgestürzt!) Wir haben buchstäblich Monate gebraucht (nicht Mannstunden, nur die Gesamtzeit), um das Problem herauszufinden. Wenn Sie den Paketmanager den gesamten Ordner steuern lassen, können Sie keine gemischten Versionen erhalten. Sie sorgen für Konsistenz. Sie erschweren auch die Verwendung inkompatibler Abhängigkeiten , indem sie alles automatisch zusammen aktualisieren, bei Bedarf verschiedene Versionen installieren oder sogar Warnungen oder Fehler ausgeben, wenn Sie versuchen, inkompatible Versionen von Bibliotheken zu verwenden.
3. Sie legen eine gemeinsame Konvention für die Verwaltung von Bibliotheken fest. Wenn neue Entwickler zu Ihrem Projekt, Team, Unternehmen usw. kommen, kennen sie wahrscheinlich die Konventionen des Paketmanagers. Dies bedeutet, dass sie keine Zeit damit verschwenden müssen, die genauen Details für die Verwaltung von Bibliotheken in Ihrer Codebasis herauszufinden.
4. Sie bieten eine Standardmethode für die Versionierung und Verteilung Ihrer eigenen Abhängigkeiten und Dateien, die nicht zu Ihrem Repository gehören. Ich habe sie sogar persönlich für einige große statische Datendateien genutzt, die meine Anwendung benötigt, sodass sie auch für die Versionierung von Dingen außer Binärcode gut geeignet sind.
5. Einige Paketmanager bieten während der Installation zusätzliche Funktionen. NuGet fügt Ihrer csproj-Datei Abhängigkeiten und Inhaltsdateien hinzu und kann der Konfigurationsdatei sogar Konfigurationselemente hinzufügen.
6. Ihre Paketlistendateien dokumentieren die Versionen Ihrer Bibliotheken an einem zentralen Ort. Ich muss nicht mit der rechten Maustaste auf eine DLL klicken und die Versionsnummer überprüfen, um herauszufinden, welche Version der Bibliothek ich verwende. In Python hat der Bibliotheksautor möglicherweise nicht einmal die Versionsnummer in die py-Dateien aufgenommen, sodass ich möglicherweise nicht einmal in der Lage bin, die Bibliotheksversion davon zu unterscheiden.
7. Sie entmutigen die maschinenweite Installation von Abhängigkeiten. Paketmanager bieten eine herkömmliche Möglichkeit, Abhängigkeiten ohne ein globales Installationsprogramm zu installieren . Wenn Sie als Optionen den Ordner lib und die globale Installation auswählen, bieten viele Bibliotheksentwickler ihre Bibliotheken primär als globale Installationen an und nicht als herunterladbare Binärdateien, die Sie selbst einrichten müssen. (Die MS-Geschichte zeigt dies. Dies gilt auch für viele Bibliotheken unter Linux.) Dies erschwert die Verwaltung mehrerer Projekte, da möglicherweise Projekte mit widersprüchlichen Versionen vorliegen und einige Entwickler die scheinbar einfachere globale Installation der Verwendung einer eigenen Bibliothek vorziehen dir.
8. Sie tendieren dazu, Hosting und Distribution zu zentralisieren. Sie müssen sich nicht mehr auf die Website dieser zufälligen Bibliothek verlassen. Wenn sie nicht mehr im Geschäft sind, werden auf der Site eines erfolgreichen Paketmanagers immer noch alle Versionen hochgeladen. Entwickler müssen auch nicht viele Websites durchsuchen, um neue Bibliotheken herunterzuladen. Sie haben eine Anlaufstelle, um zuerst zu suchen und sogar nach verschiedenen Optionen zu suchen. Es ist auch einfacher, Pakete zu spiegeln, die auf standardmäßige Weise organisiert sind, als Kopien von allem von Ad-hoc-Websites manuell zu hosten.

Sie übertreiben auch den Wert Ihrer "Vorteile".

1. Kein externes Tool zum Verwalten von Paketen erforderlich.

   "Extern" zu was? Ich checke die NuGet-Programmdatei in meine Repositories ein. Es ist die einzige Binärdatei, bei der ich mich in Ordnung fühle, da sie klein ist und bedeutet, dass ich keine anderen Binärdateien einchecken muss.

   pip bereitet in dieser Hinsicht keine Probleme, da es jetzt standardmäßig mit Python gebündelt ist und inkompatible Änderungen in Abwärtsrichtung äußerst selten sind. Sie werden Python-Code sowieso nicht entwickeln, ohne Python extern in Ihrem Projekt installiert zu haben.

   Zu dem Zeitpunkt, zu dem sie eine breite Akzeptanz erreichen, sind die Paketmanager in der Regel sehr stabil. Ohne eine Art global installiertes Tool für die meisten Projekte kommt man nicht davon, und ein einziger Paketmanager ist eine recht leichte Anforderung. Es ist normalerweise nicht viel umständlicher, als die Sprach-Laufzeit zu installieren.

2. Zum Aufbau ist keine Internetverbindung erforderlich.

   Ich kann ohne Netzwerkverbindung keine Verbindung zu meiner Datenbank herstellen. Wenn die Datenbank von Amazon gehostet wird, benötige ich trotzdem eine vollständige Internetverbindung. Ich benötige eine Internetverbindung, um Änderungen über die Quellcodeverwaltung zu übertragen und abzurufen. Ein Build-Server kann auch ohne irgendeine Netzwerkverbindung keinen Code zum Erstellen auschecken. Ohne diese können Sie keine E-Mails senden oder empfangen . Sie können keine Bibliotheken herunterladen, um sie ohne eine in Ihrem lib-Ordner abzulegen! Eine dauerhafte Entwicklung ohne Internetverbindung ist so gut wie unbekannt. In einigen seltenen Fällen, in denen dies erforderlich ist, können Sie die Pakete an einen Speicherort herunterladen, den der Paketmanager verwenden kann. (Ich weiß, dass NuGet und pip sehr gerne von einem einfachen Ordner oder Netzwerklaufwerk abrufen. Ich vermute, die meisten anderen können das auch.)

3. Schnellere Erstellung (keine Paketprüfung).

   30 Sekunden während des automatischen Builds und 5 Sekunden während des Builds lokaler Entwickler sind ein guter Kompromiss für die oben beschriebenen Vorteile. Dies sind triviale Zeitrahmen, die im Vergleich zu den Problemen, die die Vorteile lösen, normalerweise nicht einmal in Betracht gezogen werden sollten.

4. Einfachere Umgebungen (weniger Kenntnisse erforderlich).

   Ein Tool für die Paketverwaltung gegen nichts für die Bibliotheksverwaltung ist ohnehin kein fairer Vergleich. Ohne das Tool müssen Sie lernen, welchen benutzerdefinierten Prozess das Projekt verwendetum seine Bibliotheken zu verwalten. Dies bedeutet, dass Sie nie sicher sind, ob Ihr vorhandenes Wissen für ein neues Projekt gilt, an das Sie sich wenden. Sie müssen sich mit jeder Art von Trick beschäftigen, die sich jemand ausgedacht hat, oder sich selbst etwas einfallen lassen. Das könnte ein Verzeichnis sein, das alle Bibliotheken enthält, oder etwas viel Seltsameres. Vielleicht, um zu vermeiden, dass die Bibliotheken eingecheckt werden, hat jemand sie alle auf einem Netzwerklaufwerk abgelegt, und die einzige Versionsanzeige ist der Ordnername. Wie ist das oder eine globale Installation wirklich besser? Im Vergleich dazu bietet Ihnen ein Paketmanager eine saubere Konvention, die für die meisten Projekte gilt, auf die Sie stoßen.

Das gemeinsame Thema ist, dass sie Konsistenz, Dokumentation und Funktionen nicht nur innerhalb von Projekten, sondern auch über sie hinweg bieten. Dies vereinfacht das Leben aller.

Nachdem unser Produkt kürzlich von manuell heruntergeladenen Bibliotheken auf automatische Paketverwaltung mit Nuget umgestellt wurde, kann ich sagen, dass die Verwendung eines Paketmanagers enorme Vorteile hat.

Unser Produkt wird in 27 C # -Projekten implementiert, was nach heutigen Maßstäben relativ klein ist. Einige unserer Abhängigkeiten von Drittanbietern bestehen aus Dutzenden von Assemblys.

Wenn ich vor Nuget alle unsere Abhängigkeiten auf die neueste Version aktualisieren wollte, müsste ich:

1. Finden Sie heraus, wo ich alle aktualisierten Bibliotheken finden kann
2. Laden Sie sie herunter und entpacken / installieren Sie sie
3. Fügen Sie der Quellcodeverwaltung die neuen Versionen hinzu
4. Sehen Sie sich alle Referenzen in unseren Projekten manuell an und aktualisieren Sie sie, um auf die neuen Baugruppen zu verweisen

Bei 27 Projekten und Dutzenden von Abhängigkeitsassemblys war dieser Prozess sehr fehleranfällig und konnte Stunden dauern.

Jetzt, da wir auf Nuget umgestellt haben, kann ich alles mit einem einzigen Befehl erledigen.

Kein externes Tool zum Verwalten von Paketen erforderlich

Das ist eine Art Nicht-Punkt, oder? Wenn ich einen Paketmanager verwende, muss ich keinen lib-Ordner haben. Ich muss die Pakete auch nicht selbst verwalten.

Zum Aufbau ist keine Internetverbindung erforderlich

Abgesehen davon, dass es heutzutage etwas selten ist, während der Entwicklung keine Internetverbindung zu haben (vielleicht mit Ausnahme von unterwegs), sollte ein anständiger Paketmanager nicht erfordern, dass Sie die neueste Version haben, um Ihre Anwendung zu erstellen. Es könnte sich beschweren, aber es gibt keinen Grund, nicht mit der bereits installierten Version zu bauen

Schnellere Erstellung (keine Paketprüfung)

Das ist ein ziemlich geringfügiger Geschwindigkeitsschub, aber dafür kann man wohl einen Punkt machen.

Einfachere Umgebungen (weniger Kenntnisse erforderlich)

Die meisten Paketmanager sind heutzutage so einfach, dass es sich kaum lohnt, sie zu umgehen. Es gibt sogar visuelle Kunden, wenn Sie möchten. Sie verstecken tatsächlich einen Großteil des Getreides, das gerade läuft.

Mit den Paketmanagern können Sie diese Pakete auch für verschiedene Projekte freigeben. Wenn 5 meiner Projekte dieselbe Version von Boost verwenden, muss dies nicht für jedes Projekt dupliziert werden. Dies gilt insbesondere für die komplexen Abhängigkeitsbäume, von denen Sie sprechen.

Mit einem lib-Ordner verwalten Sie Pakete nur für dieses Projekt, während ein Paketmanager dies für Ihre gesamte Entwicklungsumgebung mit einem einzigen Tool ermöglicht.

Es ist der Unterschied zwischen der Verwendung von Bibliotheken (lib-Verzeichnis) und der Verwaltung von Metainformationen (Paketmanager) . Solche Metainformationen betreffen Versionsnummern, (transitiven) Abhängigkeiten zwischen Bibliotheken und dergleichen.

Die Diskussionen über DLL-Hölle, Bibliothekskompatibilität, Java-Modul-System, OSGi und dergleichen sollten zumindest ausreichend sein, um davon zu überzeugen, dass es sich um eine Art Abhängigkeitsmanagement handelt.

• Probleme mit Bibliotheksversionen und -abhängigkeiten können Zeitverschwendung sein.

Außerdem bietet ein freigegebenes (lokales) Repository den Vorteil, dass mehrere Projekte keine Kopien der importierten Bibliotheken verwalten müssen. Wenn man ein Projekt mit 20 Submodulen hat, haben einige dieser Module 40 ungerade Abhängigkeiten.

• Mehr Struktur
• Mehr Beschneiden von Bibliotheken
• Keine ad-hoc menschlichen Entscheidungen über Bibliotheken

In einigen Fällen kann ein lib-Ordner erforderlich sein, z. B. wenn veraltete Bibliotheken (eine Version davon wird nicht mehr verwaltet / ist nicht verfügbar), eine lokal geänderte Version einer Bibliothek usw. verwendet werden.

Für alles andere ist es so, als würde der Entwickler die Rolle des Paketmanagers übernehmen:

• Der Entwickler muss die Bibliotheken herunterladen (Internet erforderlich)
• Der Entwickler muss manuell nach neueren Versionen suchen
• ...

Und meiner Meinung nach sind weniger Kenntnisse erforderlich, da Sie mehr über die Verwendung des externen Tools, aber weniger über die Bibliotheken (dh Abhängigkeiten) lernen müssen.

Es gibt ein weiteres Problem, das von anderen Fragen nicht abgedeckt wird: das Teilen von Deps.

Angenommen, Sie haben zwei Pakete , die dieselbe Bibliothek erstellen. Im besten Fall gibt es keine Coflicts, sondern denselben Festplatten- / SSD-Speicherplatz, der zweimal verwendet wird. Im schlimmsten Fall wird es verschiedene Konflikte geben, wie z. B. Versionen.

Wenn Sie den Paket-Manager verwenden, wird die Bibliothek nur einmal (pro Version) installiert und der Pfad bereits angegeben.

PS: Natürlich benötigen Sie eine dynamische Verknüpfung (oder eine ähnliche Funktion in Ihrer Sprache), um diesen Profi zu erhalten.

Ein Hauptgrund, warum gemeinsam genutzte Bibliotheken in Unix- und Windows-Systemen der 90er Jahre als Fortschritt angesehen wurden, war, wie sie die RAM-Auslastung senken konnten, wenn mehrere Programme mit demselben Satz von Bibliotheken geladen wurden. Code-Speicherplatz muss nur EINMAL pro genauer Bibliothek und Version dieser Bibliothek zugewiesen werden. Die einzige verbleibende Speicherverwendung pro Instanz betrifft statische Variablen.

Viele Betriebssysteme implementieren gemeinsam genutzte Bibliotheken auf eine Art und Weise, die von Mechanismen wie der Unix-API mmap () abhängt. Dies impliziert, dass eine Bibliothek nicht nur dieselbe Version, sondern tatsächlich dieselbe DATEI haben muss. Dies ist für ein Programm, das seine eigenen Bibliotheken enthält, einfach nicht voll auszunutzen.

Angesichts der Tatsache, dass Speicher weitaus billiger ist und Bibliotheksversionen vielfältiger benötigt werden als in den 90er Jahren, hat dieses Argument heute nicht mehr so ​​viel Gewicht.