Qu'y a-t-il dans le dossier «contrib»?

Les projets de logiciels à code source ouvert ont souvent un dossier appelé "contrib". Par exemple, Django en a un . Pourquoi est-ce?

Il est un logiciel qui a été contrib UTED au projet, mais qui pourrait ne pas être maintenu en fait par les développeurs principaux. Le nom "contrib" ou "Contrib" est une convention établie de longue date, mais son nom n'a vraiment rien de spécial, et il n'est généralement utilisé que par des projets assez volumineux.

En regardant les projets open source populaires qui me viennent à l’esprit, je ne vois aucune mention d’un dossier «contrib»:

• jQuery ,
• Express ,
• Sass ,
• MOINS ,
• MongoDB ,
• Redis ,
• Marionnette ,
• Chef
• NUnit ,
• Ruby on Rails ,
• Laravel ,
• Jenkins ,
• Clojure ,
• Ruby .

Le seul qui a un dossier "contrib" est Django. Pour Django, le rôle de ce dossier est déjà expliqué dans la documentation :

Django vise à suivre la philosophie de Python «batteries incluses». Il est livré avec une variété d’outils supplémentaires facultatifs qui résolvent les problèmes courants de développement Web.

Ce code existe django/contribdans la distribution Django. Ce document donne un aperçu des paquets dans contrib, ainsi que de leurs dépendances éventuelles.

Le chapitre 16 du Livre Django contient une description plus détaillée du rôle de ce répertoire et de la liste de son contenu.

Un autre exemple est Solr . Avec gitstats, nous pouvons obtenir les statistiques sur les contributeurs.

Robert Muir         22.09%
Michael McCandless  13.60%
Mark Robert Miller   9.73%
Uwe Schindler        8.17%
Yonik Seeley         5.56%
Steven Rowe          5.55%

Ensuite, nous pouvons sélectionner uniquement le contribrépertoire en exécutant:

git filter-branch --subdirectory-filter solr/contrib --prune-empty

et obtenez les statistiques une fois de plus:

Robert Muir         19.62%
Steven Rowe          8.87%
Mark Robert Miller   8.33%
Uwe Schindler        8.06%
James Dyer           7.80%

Les meilleurs auteurs sont pratiquement les mêmes, ce qui signifie que ce ne sont pas des contributions de personnes extérieures. En regardant les répertoires à l’intérieur du contribdossier, il semble qu’une fois de plus, ce sont «une variété d’outils supplémentaires facultatifs», exactement comme dans Django. Par exemple, vous n'avez pas besoin du gestionnaire de demandes d'importation de données pour que Solr fonctionne, mais si vous souhaitez importer des données à partir d'une base de données ou d'un fichier XML, il est agréable de les avoir dans un contribdossier. Même chose pour map-réduire, vous n’en aurez peut-être pas nécessairement besoin, mais dans certains cas.

Est-ce que ces plugins ou add-ons? Je n'utiliserais pas ce terme. Les plugins et add-ons ont une intégration spécifique avec l'application principale. Par exemple, un plugin ne devrait pas fonctionner de manière autonome, mais hébergé dans l'application principale. D'autre part, contribcontient des outils qui peuvent probablement fonctionner de manière autonome.

Il est destiné aux bibliothèques ou aux composants qui contribuent au projet, mais ne sont pas possédés ou ne font pas partie du projet lui-même. Je l'ai toujours utilisé comme emplacement commun ou partagé pour placer les bibliothèques tierces que j'utilise.

Par exemple, vous pourriez avoir:

• / Contrib / log4net-xxx
• /Contrib/SSH.NET-xxx
• / BackendService
• / DesktopUI
• / GenUtils
• / SMCore
• / WebUI

Ensuite, référencez-les dans chacun des composants du projet en utilisant des chemins relatifs, de sorte qu'aucune sorte d'installation ou de configuration ne soit nécessaire avant de le construire. Il sera construit directement à partir du repo, peu importe où il est extrait localement.

Git est un excellent exemple de logiciel open source qui utilise cette convention:

https://github.com/git/git/tree/master/contrib

Voici un extrait pertinent de ce fichier README.md:

Logiciel fourni

Bien que ces éléments soient disponibles dans l’arbre source officiel de git, leur statut est légèrement différent. L’intention est de conserver ici des outils intéressants, peut-être même expérimentaux, autour de git, afin de permettre aux utilisateurs d’y accéder plus facilement et d’offrir une plus grande visibilité aux outils, de manière à ce qu’ils puissent être améliorés plus rapidement.

Je ne compte pas trop les toucher moi-même. En ce qui concerne mon fonctionnement quotidien, ces sous-répertoires appartiennent à leurs auteurs principaux respectifs. Je suis disposé à aider si les utilisateurs de ces composants et les «propriétaires» de contributions / sous-arbres ont des problèmes techniques / de conception à résoudre, mais l'initiative visant à réparer et / ou améliorer les choses doit être du côté des propriétaires de sous-arbres.