web-dev-qa-db-fra.com

Quelle est la différence entre les dossiers "lib" et "vendor"?

En ce qui concerne la hiérarchie des dossiers source, il existe toujours des fonctionnalités communes, telles que les dossiers src, doc ou test, qui ont un contenu assez facile à comprendre.

Cependant, j'ai réalisé que les grands projets ont à la fois un dossier lib et vendor, alors que j'avais toujours pensé qu'ils étaient les mêmes, car leurs noms suggèrent d'inclure "tiers libraries depuis l'externe vendors ”. Cependant, voir les deux dans le même projet signifie qu'il y a une différence .

Je n'ai trouvé aucune information ni sur Google ni sur des sources telles que Filesystem Hierarchy Standard , même si c'est en fait une pratique quelque peu courante .

Voici un exemple plus détaillé avec Symfony : une fois que vous avez créé un projet, vous obtenez un dossier lib à la racine de votre projet. Dans ce dossier, la structure suivante se trouve:

lib
+--filter
+--form
+--…
+--vendor
    +--simpletest
    +--symfony

Ici, le dossier symfony contient tout le noyau de Symfony.

directory-structure
106
MattiSG

Généraliser la réponse de @ WayneM mais sans oser autant la modifier.

Il semble donc que cette structure puisse être observée dans les frameworks d'application (Rails et Symfony au moins).

C'est un moyen de conserver intacte la structure lib/src pour les développeurs d'applications, tout en ajoutant l'autre niveau de distance apporté par l'utilisation d'un framework: le dossier vendor contient en fait les bibliothèques du framework, laissant le dossier lib pour les bibliothèques incluses de l'application et src pour ses fichiers source.

C'est un lib "plus distant", vital car sans le framework, l'application est inutile, mais ne doit pas être touchée par le développeur de l'application: ce sont les librairies du framework framework.

21
MattiSG

Quand je vois un répertoire lib ou libraries, je pense à:

  • Bibliothèques, pas plugins, modules, etc.
  • OOP au lieu de procédural, le cas échéant (c'est-à-dire PHP)

Quand je vois un répertoire vendor, je pense à:

  • Bibliothèques, plugins, modules, composants, etc. Pas seulement des bibliothèques, mais tout ce qui est fourni par un tiers.
  • Et des trucs qui ne sont pas du code, comme un jeu d'icônes.

Quand je vois les répertoires lib et vendor, je pense à quelques distinctions:

  1. lib ne contient que des bibliothèques, vendor peut contenir vraiment n'importe quoi,
  2. lib est l'endroit où je devrais mettre mes bibliothèques, vendor où je devrais mettre quelque chose de tiers (y compris le code de l'auteur original),
  3. lib est l'endroit où se trouvent les bibliothèques de l'auteur original du projet (si ce n'est pas moi), tandis que vendor est l'endroit où l'auteur original a mis quoi que ce soit de tiers.
  4. Vous pouvez supposer en toute sécurité que tout ce qui est dans lib est sous licence sous la même licence que le reste du projet.

Quel que soit l'un des cas ci-dessus, c'est une raison suffisante pour avoir différents dossiers. AFAIK il n'y a pas de pratique généralement acceptée. Certaines communautés ont des pratiques communes à l'échelle de la communauté, mais c'est à peu près tout.

Quant à l'exemple spécifique de Symfony: Symfony est un framework et je pense que ce que les développeurs essaient de dire, c'est que dans une application Symfony les bibliothèques de base du framework sont du code fournisseur, c'est-à-dire provenant d'un tiers et non de l'auteur original de l'application (vous).

65
yannis

Dans le cas de quelque chose comme Symfony, lib est le code de l'application (c'est-à-dire écrit par les développeurs) et vendor est le code tiers. Pensez-y comme lib est ce que le dossier src est normalement, et le vendeur est lib. Je vois normalement ce style dans PHP parce que vous séparez les modèles html des classes réelles.

10
Wayne Molina

Depuis le guide Rails Asset Pipeline :

  • app/assets est destiné aux éléments appartenant à l'application, tels que les images personnalisées, les fichiers JavaScript ou les feuilles de style.

  • lib/assets est pour le code de vos propres bibliothèques qui ne correspond pas vraiment à la portée de l'application ou aux bibliothèques partagées entre les applications.

  • vendor/assets est destiné aux actifs appartenant à des entités externes, tels que le code pour les plugins JavaScript et les frameworks CSS.

Je sais que ce n'est pas une question spécifique à Rails, mais l'explication est bonne et claire et s'étend probablement à d'autres cadres/structures de projet.

2
Chico Carvalho