Comment gérer les dépendances externes dans un projet open-source?

23

Quand on écrit un projet open-source et utilise Google Code ou GitHub, et que l'on veut utiliser une bibliothèque comme Lua, comment faire?

  • La dépendance doit-elle être incluse dans le référentiel?
  • La dépendance doit-elle être générée à partir du même script de génération que le reste du projet, ou à partir d'un script de génération distinct?

Étant donné que la bibliothèque n'a pas besoin d'installation avant la compilation.

open-source version-control dependencies à droite
la source

Réponses:

10

Je recommande fortement de lire la documentation de Git sur les sous-modules ; il résout ce problème, en supposant que toutes vos sources utilisent Git. Si ce n'est pas le cas, vous pouvez toujours configurer un référentiel git à des fins d'intégration. L'effort est insignifiant et le gain est important.

Bryan Agee
la source
1
Les sous-modules sont une implémentation plutôt faible de la gestion des dépendances en commun et dans Git. Au moins git subtree est une bien meilleure itération
Lazy Badger
4
-1 Veuillez inclure les détails du lien dans votre réponse, sinon la réponse est inutile lorsque le lien disparaît - comme c'est le cas actuellement. Malheureusement, je n'ai pas encore le représentant pour
voter contre
@Precastic: Si vous recherchez le texte du lien sur Google, il vous amène directement à la nouvelle page; Je ne sais pas à quel point cela peut être plus informatif.
Bryan Agee
1
Veuillez lire stackoverflow.com/help/how-to-answer - en particulier la section intitulée "Fournir un contexte pour les liens" (citation: "Citez toujours la partie la plus pertinente d'un lien important, au cas où le site cible serait inaccessible ou se déconnecterait définitivement . ")
Precastic
17

La dépendance doit-elle être incluse dans le référentiel?

Je pense que les dépendances devraient toujours être incluses dans le référentiel tant que les inclure ne viole aucune condition d'utilisation. Peu de choses sont plus ennuyeuses que d'avoir à trouver manuellement les bonnes versions des bonnes dépendances avant de pouvoir faire une construction. Bien sûr, cela est facile lorsque vous disposez d'outils automatisés pour le faire à votre place, qui peuvent trouver et télécharger la bonne dépendance, mais que se passe-t-il si vous n'êtes pas connecté au Web pour le moment ou si le serveur est en panne ou le projet de la dépendance a été complètement interrompu et mis hors ligne? Incluez toujours les dépendances si possible.

La dépendance doit-elle être générée à partir du même script de génération que le reste du projet, ou à partir d'un script de génération distinct?

À moins qu'il n'y ait une bonne raison de compiler à partir des sources, utilisez des versions précompilées.

Et pourquoi ne pas fournir des options dans le script de construction? Un simple commutateur pour choisir si les dépendances doivent également être compilées ou non. Si l'utilisateur choisit également de compiler les dépendances, il suffit d'appeler ses propres scripts de build à partir du script de build de votre produit. Ainsi, l'utilisateur peut invoquer manuellement les scripts de construction des dépendances ou choisir de créer une version complète de tout. Mais je livrerais les dépendances sous forme de binaires s'il n'y a pas de bonne raison de les compiler à partir des sources. Je pense que dans le monde Open Source, certaines licences vous obligent à distribuer les sources avec votre produit, mais cela ne signifie pas que vous ne pouvez pas les faire précompiler.

En bref: fournissez un ensemble de travail autonome, si possible. Cela fournira le plus de confort à vos utilisateurs.

Faucon
la source
1
@tdammers: Je sais, si votre installation de logiciel sur un système Linux, le gestionnaire de paquets fait tout le travail pour vous. Mais cela nécessite une connexion Internet et le package doit être dans un certain format et j'ai explicitement déclaré que les outils d'automatisation peuvent aider à cela. Vous ne pouvez pas utiliser un tel système pour les outils open source .NET, par exemple. Si vous jetez un œil aux outils sourceforge comme NHibernate ou Castle Windsor, vous verrez que toutes les dépendances sont incluses comme binaires. Et c'est la seule chose raisonnable à faire.
Falcon
1
@tdammers: Par coïncidence, je dois installer le SDK OpenOffice sur une machine Linux ici aujourd'hui. Étant donné que le SDK ne peut pas être installé via le gestionnaire de packages, j'ai récupéré le RPM sur le site Web. Selon vous, quel est le premier message que j'obtiens en essayant d'exécuter "rpm --install"? erreur: dépendances ayant échoué: ooobasis3.3-core01 est requis par ooobasis3.3-sdk-3.3.0-9567.x86_64 - OH JOY!
Falcon
2
@tdammers: vous avez raison, mais dans le cas, j'aimerais avoir cette redondance si seulement la configuration et l'installation étaient faciles. Et quand vous voulez voir un enfer de dépendance, jetez un œil au répertoire / usr / lib. Il y a tout: redondance, subversions et vous ne savez même pas quel programme utilise quelles bibliothèques. Bien sûr, laissez le gestionnaire de paquets s'en occuper! Mais que se passe-t-il si le gestionnaire de paquets ne peut pas le gérer comme dans le cas de bureau ouvert que j'ai mentionné. Cela signifie essentiellement que vous êtes foutu et que vous aurez du mal à installer quelque chose.
Falcon
2
@tdammers: Et plus j'y pense et plus mes expériences: je ne peux même pas compter les fois où j'ai dû créer des liens symboliques dans ce répertoire simplement parce que les dépendances ont échoué ou qu'un programme a refusé de s'exécuter, même lorsqu'il est installé via un gestionnaire de paquets. Peut-être que la situation s'est améliorée maintenant, mais il est souvent encore difficile de faire fonctionner certaines choses. Problèmes qui auraient pu être évités s'ils venaient de livrer la dépendance avec l'application. Je paierai volontiers les quelques Mo d'espace supplémentaire juste pour éviter ces tracas.
Falcon
2
@tdammers: Les innombrables tutoriels sur le Web sur la façon d'installer un programme spécifique sur un système Linux spécifique sont des témoins de ce problème.
Falcon
3

Cela peut ou non s'appliquer à votre cas d'utilisation, mais ce que nous faisons au travail est d'inclure un dossier "Références" dans chaque branche. Nous plaçons ici des DLL tierces. Cela provoque beaucoup de duplication de binaires relativement immuables dans le contrôle de code source, mais le stockage est bon marché et à tout moment chaque branche et balise a exactement les dépendances (et la version!) Qu'elle attend.

Nous précompilons les dépendances nous-mêmes et déplaçons les binaires compilés dans ce dossier. Notre propre bibliothèque partagée en interne est également traitée de cette façon. De cette façon, la même technique fonctionne pour les bibliothèques propriétaires précompilées, les bibliothèques open source et les bibliothèques internes.

En ce qui concerne la réponse à votre question maintenant que je l'ai relue, faites la même chose et mentionnez simplement que votre projet utilise une version 1.3.5 précompilée de Lua.

Bryan Boettcher
la source
1

La dépendance doit-elle être incluse dans le référentiel?

Il peut être référencé dans le référentiel (par n'importe quelle méthode utilisable pour SCM), si cette dépendance fait partie intégrante du produit (source-dépendance), pas la dépendance binaire, qui peut être résolue séparément

La dépendance doit-elle être générée à partir du même script de génération que le reste du projet, ou à partir d'un script de génération distinct?

Peu importe du tout. Vous pouvez préférer n'importe quelle méthode, selon vos besoins (rapidité / transparence / gérabilité / etc)

Blaireau paresseux
la source
0

Étant une boutique Eclipse, nous venons de commencer à utiliser Buckminster pour gérer notre processus de construction / assemblage / déploiement.

Notre première étape a été de retirer toutes nos bibliothèques dépendantes existantes et de laisser buckminster se charger de matérialiser les bonnes. Cela permet un déploiement beaucoup plus rapide et plus petit.

La prochaine étape consistera à déplacer notre svnréférentiel monolithique vers une série de gitréférentiels modulaires .

Je ne sais pas comment Buckminster s'intégrerait bien avec les gitsous-modules (ou les sous-dépôts mercuriels d'ailleurs), mais il est agréable que Buckminster soit agnostique en ce qui concerne le VCS utilisé pour un composant donné.

Mark Booth
la source