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

103

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

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

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


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

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

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

MattiSG
источник
3
@YannisRizos Я знаю, что это не в их источнике. Однако, как только вы начнете работать над проектом и сгенерировать модули, вы получите lib/vendorи другие каталоги vendor. И они не единственные . «Каждый может выбрать любую структуру режиссера » Да, хорошо, спасибо. Каждый может писать код так, как хочет. Если я хочу назвать src«woudzigouga», я могу. Я не спрашиваю, могу ли я, но почему другие серьезные и известные люди делают что-то, что выглядит как хорошая практика.
MattiSG
2
Кроме очевидного, он libсодержит основные библиотеки (абсолютно необходимые библиотеки ИЛИ библиотеки, созданные от того же автора, что и фреймворк) и vendorсодержит сторонние библиотеки, я не думаю, что есть какое-то иное вменяемое различие. Это различие несколько важно по ряду причин, и оно имеет смысл как общая практика.
Яннис
1
Кстати, не могли бы вы добавить пояснения в комментариях к самому вопросу?
Яннис
@YannisRizos Какие уточнения? Поиск кода Google, доказывающий, что мой вопрос не является полностью поддельным? На самом деле было бы полезно, если бы вы могли детализировать «множество причин», для которых важно это различие, а также объяснить, как некоторые включенные третьи стороны могут быть более существенными, чем другие - если они включены, есть причина, если только сопровождающие некомпетентны и включают пакетный код.
MattiSG
1
Вы можете касаться вещей в / lib /, вы не можете касаться вещей в / vendor /
Тимо Хуовинен

Ответы:

64

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

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

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

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

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

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

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


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

Яннис
источник
2
«Материал, который не является кодом» будет в dataили resources(или что-то более точное по линии img), ИМХО. Более того, в нашем примере Symfony vendorфактически содержит все ядро ​​Symfony, поэтому, если я не получу ваше наименование «оригинальный автор», я не думаю, что это соответствует вашим пунктам 2 и 3.
MattiSG
1
@ MattiSG Ах, извините, я не говорю, что это должно соответствовать всем четырем пунктам. Только один. И «Материал, который не является кодом» должен быть в каталоге resourcesили assets, но в зависимости от проекта это может иметь смысл в vendorкаталоге (я assetsдействительно предпочитаю ).
Яннис
4
Что лучше единственное или множественное число? libпротив libsи vendorпротив vendors?
Quang
4
@Quang Большинство популярных проектов, которые я видел, используют единственное число, но я понятия не имею, какой из них лучше.
Яннис
@YannisRizos: что заставляет вас думать о ООП, а не о процедурном?
Мэтт О'Брайен
21

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

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

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

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

MattiSG
источник
10

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

Уэйн Молина
источник
2

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

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

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

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

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

Чико Карвалью
источник