Warum werden Bibliotheken separat ausgeliefert und nicht mit jedem Programm gebündelt?

10

Ich weiß, warum dies im Allgemeinen gut ist: schnellere Sicherheitskorrekturen, einfachere Verpackung, mehr Funktionen. Ich versuche jedoch, einige Mitarbeiter davon zu überzeugen, dass wir keine Bibliothek mit unserem Programm bündeln müssen. Ohne diese Bibliothek wird es nicht funktionieren, aber die Bibliothek ist seit einiger Zeit stabil und wird dies auf absehbare Zeit bleiben. Ich sehe keinen Grund, es NICHT zu entbündeln.

Mit welchen Argumenten könnte ich sie überzeugen?

Meine spezielle Situation ist folgende: Ich arbeite an SymPy , einer Open-Source-Python-Bibliothek für symbolische Mathematik. Ein Kernstück davon ist mpmath , eine Bibliothek für Gleitkomma-Arithmetik mit mehreren Präzisionen . SymPy funktioniert nicht ohne mpmath, es gibt keine Alternative. Daher wurde es von Anfang an mit SymPy gebündelt (mir wurde gesagt, dass es normalerweise kleine Inkompatibilitäten gab, die bei jedem Import einer neuen Version behoben werden mussten). Es sollte auch beachtet werden, dass der Entwickler von mpmath früher an der SymPy-Entwicklung beteiligt war. Es gibt jetzt ein Problem bei der Entflechtung von mpmath. Sie können alles hier lesen .

Um die Diskussion dort zusammenzufassen:

Aufschlüsseln:

Etwas einfachere Portierung auf Python 3 (kleines Argument IMHO)
Einfachere Verpackung für Distributionen
Schnellere (Sicherheits-) Funktionsaktualisierungen für Benutzer
"Verpackungs- und Handhabungsabhängigkeiten sind schwierige Probleme, aber sie sind gelöst. Dies ist definitiv kein Bereich, in dem wir unser eigenes Ding machen sollten."

Weiter bündeln:

Installation. Es ist einfach unter Linux, schwieriger auf Mac und sehr schwer unter Windows. Fehlender Zugang und andere Probleme.
Es ist ein integraler Bestandteil von SymPy, dh Sympy funktioniert (überhaupt) nicht ohne SymPy.
Es gibt kein anderes Paket, das die Arbeit von mpmath erledigen kann
"Wenn ich als Benutzer Sympy herunterlade, erwarte ich, dass es einfach funktioniert."

Das ist meine spezifische Situation, aber ich würde eine Antwort akzeptieren, die auch eine gute, allgemeine Antwort liefert.

package-management

— VPeric
quelle

Sie müssen mehr Informationen zu Ihrer spezifischen Situation bereitstellen, um eine bessere Antwort zu erhalten. In welcher Umgebung möchten Sie es beispielsweise ausführen? Wird es dem Internet ausgesetzt sein?

— Tshepang

Ist Ihre Anwendung Open Source?

— Anton Barkovsky

@Anton Ja, es ist SymPy , eine Open-Source-Python-Bibliothek für symbolische Mathematik. Ich arbeite als GSoC-Student daran (vollständige Offenlegung :)).

— VPeric

@ Tshepang Die Diskussion kann gesehen werden unter: code.google.com/p/sympy/issues/detail?id=2482

— VPeric

@VPeric: Es wäre besonders schön, diese Diskussion zusammenzufassen, nur um denjenigen Zeit zu sparen, die bereit sind, Ihre Frage zu beantworten.

— Tshepang

5

Noch eine Antwort, aber eine, die ich für die wichtigste halte (nur meine persönliche Meinung), obwohl die anderen ebenfalls gute Antworten sind.

Durch das separate Packen der Bibliothek kann die Bibliothek aktualisiert werden, ohne dass die Anwendung aktualisiert werden muss. Angenommen, es gibt einen Fehler in der Bibliothek. Anstatt nur die Bibliothek aktualisieren zu können, müssten Sie die gesamte Anwendung aktualisieren. Dies bedeutet, dass Ihre Anwendung einen Versions-Bump benötigt, ohne dass sich der Code geändert hat, nur aufgrund der Bibliothek.

— Patrick
quelle

1

Dies ist ein wichtiger Punkt, und es ist ein Teil dessen, warum viele Distributionen es nicht mögen, Bibliotheken mit Programmen zu bündeln. Debian hat beispielsweise die Richtlinie, eine Bibliothek nicht mit einer ausführbaren Datei zu bündeln oder eine Bibliothek statisch zu verknüpfen, es sei denn, sie kann nur von diesem bestimmten Programm verwendet werden (oder für statische Verknüpfungen Fälle, in denen dynamische Verknüpfungen nicht unterstützt werden).

— Gilles 'SO - hör auf böse zu sein'

Am Ende ist dies vielleicht der wichtigste Punkt. Ich stimme auch den anderen Antworten zu, aber ich musste nur eine auswählen. :)

— VPeric

6

Zusätzlich zu den von Ihnen erwähnten Vorteilen (Sicherheit, Verpackung, Funktionen) kann ich mir noch einige vorstellen:

Jemand, der die Funktionalität für ein anderes Programm nützlich finden würde, müsste sie nicht aufteilen. Das heißt, wenn sie überhaupt weiß, ob die Funktionalität in Ihrem Projekt überhaupt in Form einer Bibliothek vorhanden ist. Dies hängt davon ab, wie gut es gestaltet ist ... wenn Ihr Projekt modular genug ist.
Wenn dies für andere Projekte nützlich ist, würde dies die Größe der Disc-Nutzung im Allgemeinen verringern (z. B. nur eine Kopie des Codes).
Dies würde die Qualität Ihres Codes verbessern und Sie dazu zwingen, einige (dringend benötigte) Umgestaltungen vorzunehmen. Wie im ersten Punkt oben hängt dies auch von der Qualität Ihres Codes ab.
Eine Erhöhung der Anzahl der Benutzer der Bibliothek (wenn sie aufgeteilt ist) würde dazu beitragen, sie allgemeiner zu gestalten, was wahrscheinlich auch die Qualität verbessern wird.

— Tshepang
quelle

1

Alles gute Punkte. Ich nehme an, es könnte als "zukunftssicher" gelesen werden: Derzeit gelten nur wenige Ihrer Punkte (mpmath wird derzeit nur in einigen anderen Projekten verwendet), aber es ist leicht zu erkennen, dass jeder Ihrer Punkte für jedes neue Projekt an Wert gewinnt mit mpmath.

— VPeric

4

Obwohl die Vorteile offensichtlich sind, scheint die einfache Bereitstellung das Hauptargument für den Versand der Bibliothek zusammen mit dem Programm in Ihrem Fall zu sein.

Hier einige weitere Argumente gegen die Bündelung:

Unter Linux ist es Aufgabe des Distributionsbetreuers, sicherzustellen, dass Ihre Bibliothek mit ihren Abhängigkeiten gut funktioniert. Die meisten Benutzer laden die Bibliothek in jedem Fall über den Paketmanager der Distribution herunter. Diejenigen, die Trunk verwenden, werden normalerweise nichts dagegen haben, Zeit mit der Konfiguration der Bibliothek zu verbringen.
Unter Windows und Mac OS werden Python-Paketmanager wie pip normalerweise ohnehin verwendet, da die manuelle Installation von Bibliotheken umständlich ist.
Es gab sogar Argumente für eine harte Bereitstellung in der Google App Engine, aber nicht alle Webframeworks werden darauf ausgeführt. Viele benötigen sogar eine Portierung, der Speicherplatz für Bibliotheken ist begrenzt und das Hosting von Webanwendungen schließlich! Es ist unwahrscheinlich, dass Webanwendungen symbolische Mathematik verwenden.
Niemand hindert Sie daran, saubere Fehlermeldungen anzuzeigen, wenn die Abhängigkeit nicht verfügbar ist oder die falsche Version hat.
Die Leute hassen es oft, wenn das Programm sich für schlauer hält als sie. Lassen Sie Benutzer sich um ihr eigenes System kümmern.

— Anton Barkovsky
quelle

Können Sie den letzten Punkt erklären? Ich kann nicht sagen, ob es ein Argument für / gegen die Bündelung ist.

— Tshepang

3

Ich verstehe es als gegen Bündelung - die Benutzer möchten installieren, was sie wollen, ohne dass ich ihnen eine bestimmte Version aufzwinge.

— VPeric

3

Der richtige Weg, um die Entbündelung in einem Windows-Installationspaket zu handhaben, besteht darin, den Preinst-Test auf die Existenz der Bibliothek durchzuführen und, falls nicht vorhanden, die Installation aus dem Bibliothekspaket anzubieten, das Sie in das Software-Installationspaket aufnehmen. Ich bin mir ziemlich sicher, dass die meisten GTK-Apps mit Windows-Ports etwas in diese Richtung tun - ich weiß, dass Pidgin dies tut.

— Shadur
quelle

3

Eine Größe muss nicht für alle passen.

Bei Quelldistributionen müssen Packager auf vielen Distributionen (zumindest im Debian- und Fedora-Erbe) zusätzliche Arbeit leisten, um die Bündelung zu deaktivieren oder zu entfernen, da Paketrichtlinien für diese Plattformen die Bündelung verbieten oder zumindest stark davon abhalten. Durch die Bündelung schaffen Sie daher mehr Arbeit für Ihren Downstream mit sehr geringem Nutzen. Könnte dieses Argument etwas Gewicht haben?

Binärverteilungen (wenn Sie sie bereitstellen) können in beide Richtungen gehen. Bündelung ist für diese wahrscheinlich sinnvoll, da sie nicht von Downstream verwendet werden.

Es gibt jedoch keinen Grund, warum Sie nicht die gegenteilige Entscheidung treffen und für Windows- und Mac-Installationsprogramme bündeln können.

— Michael Ekstrand
quelle

1

Obwohl ich im Allgemeinen zustimme, verursacht dies eine zusätzliche Belastung (wie gering sie auch sein mag), was bedeutet, dass wahrscheinlich niemand diese Lösung unterstützen würde.

— VPeric

2

Bündelung gegen Abhängigkeit ist eine alte Debatte in der Verpackungswelt. Dieses Dokument beschreibt diese beiden Denkrichtungen: http://www.aosabook.org/en/packaging.html

— Éric Araujo
quelle

2

Dies war eine interessante Lektüre, aber es geht mehr um die Implementierungsdetails und verschiedene Python-Besonderheiten als um die allgemeine Philosophie.

— VPeric