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.
la source
lib/vendorautres répertoiresvendor. 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 appelersrc«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.libcontient les bibliothèques de base (bibliothèques absolument essentielles OU bibliothèques construites à partir du même auteur que le framework) etvendorles 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.Réponses:
Quand je vois un répertoire
liboulibraries, je pense à:Quand je vois un
vendorrépertoire, je pense à:Quand je vois
libetvendorré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 quevendorc'est l'endroit où l'auteur original a mis quelque chose de tiers.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).
la source
dataouresources(ou quelque chose de plus précis dans le sens deimg), à 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.resourcesouassets, mais selon le projet, cela peut avoir un sens dans unvendorrépertoire (je préfèreassetsvraiment).libvslibsetvendorvsvendors?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: levendordossier contient en fait les bibliothèques du framework, laissant lelibdossier pour les bibliothèques incluses de l'application etsrcpour 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 .la source
Dans le cas de quelque chose comme Symfony,
libest le code de l'application (c'est-à-dire écrit par les développeurs) etvendorest du code tiers. Pensez-y comme si lib était ce que lesrcdossier é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.la source
Dans le guide Rails Asset Pipeline :
app/assetsest destiné aux actifs appartenant à l'application, tels que des images personnalisées, des fichiers JavaScript ou des feuilles de style.lib/assetsest 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/assetsest 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.
la source