¿Cuál es la diferencia entre las carpetas "lib" y "vendor"?

Con respecto a la jerarquía de carpetas de origen, siempre hay algunas características comunes, tales como el src, doco testcarpetas, que tienen bastante fácil de entender el contenido.

Sin embargo, me di cuenta de que los grandes proyectos tienen tanto una liby vendorcarpetas, mientras que yo siempre había pensado que eran los mismos, como sus nombres hacen alusión a que incluye “terceros librariesdesde el exterior vendors”. Sin embargo, al ver tanto en el mismo proyecto significa que no es una diferencia.

No pude encontrar ninguna información ni en Google ni en fuentes como el Estándar de Jerarquía del Sistema de Archivos , a pesar de que esta es una práctica común de alguna manera .

Aquí hay un ejemplo más detallado con Symfony : una vez que crea un proyecto, obtiene una libcarpeta en la raíz de su proyecto. En esta carpeta, se encuentra la siguiente estructura:

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

Aquí, la symfonycarpeta contiene todo el núcleo de Symfony.

Cuando veo un directorio libo libraries, pienso en:

• Bibliotecas, no complementos, módulos, etc.
• OOP en lugar de procedimiento, donde sea aplicable (es decir, PHP)

Cuando veo un vendordirectorio, pienso en:

• Bibliotecas, complementos, módulos, componentes, etc. No solo bibliotecas, sino cualquier cosa que sea proporcionada por un tercero.
• Y cosas que no son código, como un conjunto de iconos.

Cuando veo liby vendordirectorios, pienso en algunas distinciones:

1. libsolo contiene bibliotecas, vendorpuede contener cualquier cosa realmente,
2. libes donde debería poner mis bibliotecas, vendordonde debería poner cualquier cosa de terceros (incluido el código del autor original),
3. libes donde se encuentran las bibliotecas del autor original del proyecto (si ese no soy yo), mientras que vendores donde el autor original pone algo de terceros.
4. Puede suponer con seguridad que todo lo que está dentro libtiene licencia bajo la misma licencia que el resto del proyecto.

Cualquiera de los anteriores aplica, es razón suficiente para tener diferentes carpetas. AFAIK no existe una práctica generalmente aceptada. Algunas comunidades tienen prácticas comunes en toda la comunidad, pero eso es todo.

En cuanto al ejemplo específico de Symfony: Symfony es un marco y creo que lo que los desarrolladores intentan decir es que en una aplicación Symfony las bibliotecas centrales del marco son código de proveedor, es decir, provienen de un tercero y no del autor original de la aplicación. (tú).

Generalizando la respuesta de @ WayneM pero sin atreverse a editarla tanto.

Entonces, parece que esta estructura se puede observar en los marcos de aplicación (Rails y Symfony al menos).

Es una forma de mantener intacta la estructura lib/ srcpara los desarrolladores de aplicaciones, al tiempo que agrega el otro nivel de distancia que brinda el uso de un marco: la vendorcarpeta en realidad contiene las bibliotecas del marco, dejando la libcarpeta para las bibliotecas incluidas de la aplicación y srcpara su fuente archivos.

Es un "más distante" lib, vital ya que sin el marco, la aplicación es inútil, pero no debe ser tocada por el desarrollador de la aplicación: son las bibliotecas del proveedor del marco .

En el caso de algo como Symfony, libes el código de la aplicación (es decir, escrito por los desarrolladores) y vendores un código de terceros. Piense en ello como lib es lo que srcnormalmente es la carpeta, y el proveedor es lib. Normalmente veo ese estilo en PHP porque separas las plantillas html de las clases reales.

De la guía Rails Asset Pipeline :

• app/assets es para los activos que son propiedad de la aplicación, como imágenes personalizadas, archivos JavaScript u hojas de estilo.

• lib/assets es para el código de sus propias bibliotecas que realmente no se ajusta al alcance de la aplicación o las bibliotecas que se comparten entre las aplicaciones.

• vendor/assets es para activos que son propiedad de entidades externas, como el código para complementos de JavaScript y marcos CSS.

Sé que esta no es una pregunta específica de Rails, pero la explicación es buena y clara y probablemente se extiende a otros marcos / estructuras de proyectos.