Ich habe eine Web-Anwendung, einschließlich Front- und Backend-Code, die ich gerne zu Github schieben würde, aber, es hat derzeit einige seiner Abhängigkeiten verwaltete es seinen Quellbaum. Der Backend-Code ist Perl, und das Installieren von Modulabhängigkeiten von CPAN ist gut verstanden, also habe ich diese nicht dort. Ich habe meistens jQuery-Bibliotheken und einige andere Javascript-Bibliotheken, die Open Source sind.
%Vor%Für die Bereitstellung ist dies sehr praktisch, da ich steuern kann, welche Versionen der Bibliotheken verwendet werden, und auch nicht, um ein CDN (Content Delivery Network) zum Laden von jQuery usw. von einer entfernten Domäne zu verwenden in drei oder fünf Jahren noch online sein.
Ich bin mir jedoch nicht sicher, ob es angemessen ist, die Quelle anderer Projekte in meine Anwendung aufzunehmen, selbst wenn ich die Lizenzdateien beifüge.
Was ist der beste Weg, Abhängigkeiten wie diese in eine Open-Source-Webanwendung zu integrieren, die Abhängigkeiten zu beachten und gleichzeitig den Komfort einer funktionierenden Implementierung zu erhalten?
Haben Sie darüber nachgedacht, eine Paketverwaltung wie Bower für Ihre JS-Abhängigkeiten zu verwenden? Paket-Management für dieses Front-End-Zeug wird immer beliebter und ähnelt Backend-Modulen (CPAN, Gems, Pip, etc.)
Nichts wird für immer da sein - die Frage, die Sie hier zu beantworten versuchen, ist, wie Sie Dinge so einrichten, dass die Quellen der Wahrheit die Lebensdauer des von ihnen abhängigen Codes überdauern.
Es ist völlig in Ordnung, die Quelle in Ihren Baum aufzunehmen, wenn es nur ein paar Dinge sind und Sie von einer bestimmten Veröffentlichung abhängig sind.
Als Alternative können Sie, da Sie sowieso zu GitHub drängen, die erforderlichen Voraussetzungen austarieren, sie entsprechend für Ihre Anwendung markieren und sie dann als Git-Submodule einfügen. Auf diese Weise sind sie mindestens so lang wie die kanonische Quelle der Wahrheit für den Quellcode der Hauptanwendung.
Wenn sie jetzt nicht auf GitHub, sondern Open Source sind, ist es immer noch sinnvoll, sie GitHub selbst hinzuzufügen und dann diese neuen GitHub Repos als Submodule zu Ihrem Projekt hinzuzufügen.
Das Einbinden der Quelle in Ihr Projekt ist in Ordnung, solange Sie die Lizenz (en) befolgen. Es könnte jedoch ablenken. Jemand, der nicht mit jQuery oder sonst etwas vertraut ist, erkennt vielleicht nicht, dass es Code von Drittanbietern ist. Sie könnten Zeit damit verschwenden, hineinzugraben oder etwas, ohne zu merken, dass es nichts mit Ihrem Projekt zu tun hat.
Unabhängig davon sollten Sie die Abhängigkeiten in einer Readme-Datei dokumentieren (z. B. README, INSTALL, DEPENDS, was auch immer). Es könnte sein, dass du zur Zeit jQuery x.y.z benutzt, es aber Fehler geben kann, die sich auf deine Software auswirken. Sie können also nicht garantieren, dass feste Versionen immer ideal sind.
Normalerweise, anstatt die Quelle zu bündeln (da sie sich nicht ändern wird und so ziemlich nicht nachverfolgt werden muss), schreibe ich stattdessen eine Hilfs-Bash oder ein Perl-Programm, um die Abhängigkeiten aus dem Netz zu holen. Auf diese Weise gibt es einen einfachen Knopf, der wahrscheinlich für Leute funktioniert, die nicht viel lesen oder manuelle Arbeit machen wollen, aber Sie haben nicht das Durcheinander anderer Projekte, die Leute von Ihrem eigenen Code ablenken, und die Abhängigkeiten sind nicht nicht unnötig von Ihren Repositories verfolgt.
Anhängen:
Wenn möglich, sollten Sie es auch vorziehen, die Software von Drittanbietern vollständig von der eigenen zu trennen, damit klar ist, wo die Software von Drittanbietern beginnt und wo Ihre ist (wieder nur, damit die Leute sie nicht mit Ihrer eigenen verwechseln) führen zu unsinnigen Anfragen von Ihnen, etc.).
%Vor%Wenn es bei der Bereitstellung zusammenkommen muss, dann muss das Build-System die Dinge an die entsprechenden Stellen kopieren oder verlinken.
Ich würde auch sicherstellen, welche Art von Lizenz Sie für die App benötigen. Es gibt ein paar da draußen den Zweck von Open Source, die den Downloader ändern oder sogar die Art der Lizenz ändern und für sie verwenden können. Natürlich gibt es Variationen von GPL-Lizenzen oder sogar MIT-Lizenzen. Suchen Sie nach dem, der Ihren Bedürfnissen entspricht.
Ich denke, es gibt keine einfache "beste" Lösung für Ihre Anforderung. Ich habe viele verschiedene Ansätze in verschiedenen Projekten verwendet. Sie alle haben ganz gut geklappt. Entscheidend ist, dass Sie den Code so organisieren, dass Sie ihn über einen längeren Zeitraum problemlos verwalten können. Das ist natürlich eine ziemlich persönliche Sache.
Ich selbst benutze gerne CDN für jQuery - es hat viel mehr Vorteile als das (sehr unwahrscheinliche) Risiko, dass der google-CDN Server länger als 5 Sekunden nicht erreichbar ist. Und selbst dann können Sie einen Fail-save in Ihren Code einbauen, um Ihr lokal gehostetes jQuery-Framework zu laden, falls CDN nicht erreichbar ist, wie folgt:
%Vor%Über die Codeorganisation: Ich bevorzuge es, meine Dateien in der folgenden Struktur zu verwalten
%Vor%In meinem Ansatz schließe ich immer alle externen Dateien in den Anwendungs-Snapshot ein (z. B. einschließlich der Versionsnummern von jquery und anderen Bibliotheken), weil schließlich die Anwendung für eine bestimmte externe Bibliothek erstellt, getestet und von dieser abhängig ist; Daher möchte ich diese Bibliotheken mit dem Code "fest verknüpfen", da sie eine einzige Einheit bilden.
Ich empfehle also, keine git-Submodule zu verwenden, sondern ein einziges Repository, das alle Dateien enthält, über die Sie die Kontrolle haben. Verwenden Sie jedoch CDN, um Bibliotheken zu laden (Sie können genau steuern, welche Version geladen werden soll, was diese Lösung perfekt macht). Eine neue Version von jQuery? Zuerst implementieren Sie es lokal, testen Sie es und fügen Sie dann die neue jQuery-Datei zum Ordner / js / lib hinzu (überschreiben Sie nicht die alte, sondern fügen Sie eine neue Datei mit eindeutiger Versionsnummer hinzu)
Tags und Links jquery perl github open-source