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

103

En ce qui concerne la hiérarchie des dossiers source, il y a toujours quelques traits communs, tels que le src, docou les testdossiers qui ont assez facile à comprendre le contenu.

Cependant, je me suis rendu compte que les grands projets avaient à la fois un dossier libet un vendordossier, alors que j'avais toujours pensé qu'ils étaient identiques, car leur nom l'indique, y compris «tiers librariesde l'extérieur 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 la norme de hiérarchie des systèmes de fichiers , même s'il s'agit en fait d'une pratique courante .

Voici un exemple plus détaillé avec Symfony : une fois que vous créez un projet, vous obtenez un libdossier à la racine de votre projet. Dans ce dossier, la structure suivante est trouvée:

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

Ici, le symfonydossier contient tout le noyau de Symfony.

directory-structure

— MattiSG
source

3

@YannisRizos Je sais que ce n'est pas dans leur source. Une fois que vous commencez à travailler sur un projet et générez des modules, vous vous retrouverez avec d' lib/vendorautres répertoires vendor. Et ils ne sont pas les seuls . “Tout le monde peut choisir n'importe quelle structure de répertoire ” Ouais, merci. Tout le monde peut coder comme il veut. Si je veux appeler src«woudzigouga», je le peux. Je ne demande pas si je peux le faire mais pourquoi d'autres personnes sérieuses et connues font quelque chose qui ressemble à une bonne pratique.

— MattiSG

2

Hormis l'évidence, qui libcontient les bibliothèques de base (bibliothèques absolument essentielles OU bibliothèques construites à partir du même auteur que le framework) et vendorles bibliothèques tierces, je ne pense pas qu'il y ait une autre distinction sensée. Cette distinction est assez importante pour diverses raisons et elle est logique en tant que pratique générique.

— yannis

1

Au fait, pourriez-vous ajouter les clarifications dans les commentaires à la question elle-même?

— Yannis

@YannisRizos Quelles clarifications? La recherche de code Google prouvant que ma question n'est pas totalement fausse? Il serait utile de pouvoir détailler la "variété de raisons" pour lesquelles la distinction est importante, ainsi que d'expliquer comment certaines tierces parties incluses peuvent être plus essentielles que d'autres - si elles sont incluses, il y a une raison, à moins que le les responsables sont incompétents et comprennent le code par lots.

— MattiSG

1

Tu peux toucher des choses dans / lib /, tu ne peux pas toucher des choses dans / vendeur /

— Timo Huovinen

64

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

Bibliothèques, pas plugins, modules, etc.
POO au lieu de procédure, le cas échéant (PHP)

Quand je vois un vendorrépertoire, je pense à:

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

Quand je vois libet vendorrépertoires, je pense à quelques distinctions:

libne contient que des bibliothèques, vendorpeut contenir quelque chose de vraiment,
libest l'endroit où je devrais mettre mes bibliothèques, vendoroù je devrais mettre n'importe quoi de tiers (y compris le code de l'auteur original),
libest l'endroit où se trouvent les bibliothèques de l'auteur original du projet (si ce n'est pas moi), alors que vendorc'est l'endroit où l'auteur original a mis quelque chose de tiers.
Vous pouvez supposer en toute sécurité que tout ce qui se trouve libest sous licence sous la même licence que le reste du projet.

Quel que soit ce qui précède s’applique, une raison suffisante pour avoir différents dossiers. Autant que je sache, il n’ya pas de pratique généralement acceptée. Certaines communautés ont des pratiques communes, mais c'est à peu près tout.

En ce qui concerne l'exemple spécifique de Symfony: Symfony est un framework et je pense que les développeurs tentent de dire que, dans une application Symfony, les bibliothèques principales du framework sont du code fournisseur, c'est-à-dire qu'elles proviennent d'un tiers et non de l'auteur original de l'application. (toi).

— Yannis
source

2

“Des choses qui ne sont pas du code” seraient dans dataou resources(ou quelque chose de plus précis dans le sens de img), à mon humble avis. De plus, dans notre exemple Symfony, vendorcontient tout le noyau de Symfony. Par conséquent, à moins de ne pas avoir la dénomination «auteur original», je ne pense pas que cela corresponde à vos points 2 et 3.

— MattiSG

1

@ MattiSG Ah, désolé, je ne dis pas que cela devrait correspondre aux quatre points. Juste un. Et "les éléments qui ne sont pas du code" doivent figurer dans un répertoire resourcesou assets, mais selon le projet, cela peut avoir un sens dans un vendorrépertoire (je préfère assetsvraiment).

— Yannis

4

Quoi de mieux au singulier ou au pluriel? libvs libset vendorvs vendors?

— Quang

4

@Quang Les projets les plus populaires que j'ai vus utilisent au singulier, mais je ne sais pas lequel est le meilleur.

— Yannis

@YannisRizos: qu'est-ce qui vous fait penser à la POO plutôt qu'à la procédure?

— Matt O'Brien

21

Généraliser la réponse de @ WayneM sans oser l'éditer autant.

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

C'est un moyen de conserver la structure lib/ srcpour les développeurs d'applications, tout en ajoutant l'autre niveau de distance apporté par l'utilisation d'un framework: le vendordossier contient en fait les bibliothèques du framework, laissant le libdossier pour les bibliothèques incluses de l'application et srcpour son source. des dossiers.

C'est un «plus distant» lib, 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 bibliothèques du fournisseur du framework .

— MattiSG
source

10

Dans le cas de quelque chose comme Symfony, libest le code de l'application (c'est-à-dire écrit par les développeurs) et vendorest du code tiers. Pensez-y comme si lib était ce que le srcdossier était normalement, et le vendeur était lib. Je vois normalement ce style en PHP parce que vous séparez les modèles HTML des classes réelles.

— Wayne Molina
source

2

Dans le guide Rails Asset Pipeline :

app/assets est destiné aux actifs appartenant à l'application, tels que des images personnalisées, des fichiers JavaScript ou des 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 qui sont partagées entre les applications.
vendor/assets est destiné aux actifs appartenant à des entités extérieures, 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.

— Chico Carvalho
source