В чем разница между папками «lib» и «vendor»?

Что касается иерархии исходных папок, всегда есть некоторые общие функции, такие как src, docили testпапки, которые имеют довольно простое для понимания содержимое.

Тем не менее, я понял, что в больших проектах есть libи vendorпапки, и папки, хотя я всегда думал, что они одинаковы, поскольку их названия намекают на то, что они «сторонние librariesиз внешних vendors». Хотя, видеть оба в одном и том же проекте значит, что есть разница.

Я не смог найти никакой информации ни о Google, ни о таких источниках, как Стандарт иерархии файловых систем , хотя это на самом деле довольно распространенная практика.

Вот более подробный пример с Symfony : после создания проекта вы получаете libпапку в корне вашего проекта. В этой папке находится следующая структура:

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

Здесь symfonyпапка содержит все ядро ​​Symfony.

Когда я вижу каталог libили libraries, я думаю о:

• Библиотеки, а не плагины, модули и т. Д.
• ООП вместо процедурного, где это применимо (например, PHP)

Когда я вижу vendorкаталог, я думаю о:

• Библиотеки, плагины, модули, компоненты и т. Д. Не только библиотеки, но и все, что предоставляется третьей стороной.
• И вещи, которые не код, как набор иконок.

Когда я вижу libи vendorкаталоги, я думаю о нескольких различиях:

1. libсодержит только библиотеки, vendorможет содержать что угодно
2. libгде я должен поместить свои библиотеки, vendorкуда я должен поместить что-либо третье лицо (включая код оригинального автора),
3. libгде находятся библиотеки автора оригинального проекта (если это не я), тогда vendorкак автор оригинала помещает что-либо третьему лицу.
4. Вы можете смело предположить, что все, что находится в lib, лицензируется по той же лицензии, что и остальная часть проекта.

Независимо от того, что из перечисленного выше применимо, достаточно иметь разные папки. AFAIK нет общепринятой практики. В некоторых сообществах распространены общие практики, но это все.

Что касается конкретного примера Symfony: Symfony - это фреймворк, и я думаю, что разработчики пытаются сказать, что в приложении Symfony основные библиотеки фреймворка представляют собой код поставщика, то есть исходящий от третьей стороны, а не от первоначального автора приложения. (вы).

Обобщая ответ @ WayneM, не осмеливаясь так сильно его редактировать.

Таким образом, кажется, что такую ​​структуру можно наблюдать в каркасах приложений (по крайней мере, Rails и Symfony).

Это способ сохранить lib/ srcструктуру без изменений для разработчиков приложений, добавив при этом другой уровень расстояния , обеспечиваемый использованием инфраструктуры: vendorпапка фактически содержит библиотеки платформы, оставляя libпапку для включенных библиотек приложения и srcдля его источника файлы.

Это «более отдаленное» lib, жизненно важное значение, поскольку без фреймворка приложение бесполезно, но разработчик приложения не должен его трогать: это библиотеки вендора фреймворка .

В случае чего-то вроде Symfony, libэто код приложения (то есть написанный разработчиками) и vendorсторонний код. Думайте об этом как о том, что srcпапка lib - это обычно папка, а vendor - lib. Я обычно вижу этот стиль в PHP, потому что вы отделяете HTML-шаблоны от реальных классов.

Из руководства Rails Asset Pipeline :

• app/assets предназначен для активов, которые принадлежат приложению, таких как пользовательские изображения, файлы JavaScript или таблицы стилей.

• lib/assets предназначен для кода ваших собственных библиотек, который на самом деле не вписывается в сферу применения или тех библиотек, которые совместно используются приложениями

• vendor/assets предназначен для активов, которые принадлежат сторонним объектам, таким как код для плагинов JavaScript и CSS-фреймворки.

Я знаю, что это не специфичный для Rails вопрос, но объяснение хорошее и ясное и, вероятно, распространяется на другие фреймворки / структуры проекта.