Яка різниця між папками "lib" та "vendor"?

103

Щодо ієрархії вихідних папок, завжди є деякі загальні особливості, наприклад src, docабо testпапки, які містять досить простий для розуміння вміст.

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

Я не міг знайти жодної інформації ні в Google, ні в таких джерелах, як стандарт ієрархії файлової системи , хоча це насправді є якось звичною практикою.

Ось більш детальний приклад із Symfony : щойно ви створюєте проект, ви отримуєте libпапку в корені проекту. У цій папці знайдено таку структуру:

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

Тут symfonyпапка містить все ядро Symfony.

directory-structure

— MattiSG
джерело

3

@YannisRizos Я знаю, що це не в їх джерелі. Як тільки ви почнете працювати над проектом і генерувати модулі, однак, ви закінчите lib/vendorі інші каталоги разом vendor. І вони не єдині . "Кожен може вибрати будь-яку структуру dir" Так, дякую. Кожен може кодувати, скільки хоче. Якщо я хочу зателефонувати src"wddigigga", я можу. Я не запитую, чи можу я, але чому інші, хто є серйозними та відомими, роблять щось, що виглядає як хороша практика.

— MattiSG

2

Крім очевидних, що libмістить основні бібліотеки (абсолютно необхідні бібліотеки АБО бібліотеки, побудовані з того самого автора, що і фреймворк), і vendorмістить бібліотеки сторонніх організацій, я не думаю, що існує якесь інше чітке розрізнення. Ця різниця є дещо важливою з різних причин, і вона має сенс як загальна практика.

— янніс

1

btw, ви могли б додати пояснення в коментарі до самого питання?

— янніс

@YannisRizos Які роз'яснення? Пошук у коді Google, який підтверджує моє запитання, не є абсолютно невірним? Насправді, було б корисно, якщо ви могли б детально ознайомитись із "різними причинами", для яких важлива різниця, а також пояснити, як деякі включені треті сторони можуть бути важливішими за інших - якщо вони включені, є причина, якщо тільки сервісні засоби - некомпетентний і пакетний код.

— MattiSG

1

Ви можете торкнутися речей у / lib /, не можете торкатися речей у / vendor /

— Timo Huovinen

64

Коли я бачу каталог libабо librariesкаталог, я думаю про:

Бібліотеки, а не плагіни, модулі тощо.
OOP замість процедурних, де це застосовується (тобто PHP)

Коли я бачу vendorкаталог, я думаю про:

Бібліотеки, плагіни, модулі, компоненти тощо. Не лише бібліотеки, а все, що надається третьою стороною.
І речі, які не є кодом, як набір іконок.

Коли я бачу libі vendorкаталоги, я думаю про кілька відмінностей:

libвміщує лише бібліотеки, vendorможе вмістити щось дійсно,
libде я повинен розмістити свої бібліотеки, vendorкуди я повинен поставити що-небудь третьої сторони (включаючи код оригіналу автора),
libтам, де знаходяться бібліотеки від оригінального автора проекту (якщо це не я), тоді як vendorавтор оригіналу поставив щось третє.
Можна сміливо припускати, що все, що є lib, ліцензується за тією ж ліцензією, що і решта проекту.

Незалежно від того, що застосовується вище, достатньо причин для того, щоб мати різні папки. AFAIK не існує загальновизнаної практики. У деяких громадах є спільна практика спільноти, але це лише про це.

Що стосується конкретного прикладу Symfony: Symfony є рамкою, і я думаю, що розробники намагаються сказати, що в додатку Symfony основні бібліотеки рамки є кодом постачальника, тобто надходить від третьої сторони, а не від оригінального автора програми. (ви).

— яніс
джерело

2

"Речі, які не є кодом" будуть в dataабо resources(або щось більш точне в рамках img), IMHO. Більше того, у нашому прикладі Symfony vendorнасправді міститься все ядро Symfony, тому, якщо я не отримаю номіналу вашого «оригінального автора», я не думаю, що відповідає вашим пунктам 2 та 3.

— MattiSG

1

@MattiSG Ах, вибачте, я не кажу, що він повинен відповідати всім чотирма пунктам. Тільки один. І "речі, які не є кодом" повинні бути в каталозі resourcesабо в assetsкаталозі, але залежно від проекту це може мати сенс у vendorкаталозі (я вважаю за краще assetsдійсно).

— янніс

4

Що краще однини чи множини? libvs libsі vendorvs vendors?

— Кван

4

@Quang Більшість популярних проектів, які я бачив, використовують однини, але я не маю уявлення, який з них кращий.

— янніс

@YannisRizos: що змушує вас думати про OOP замість процесуального?

— Метт О'Брайен

21

Узагальнення відповіді @ WayneM, але не наважуючись її так сильно редагувати.

Отож, схоже, цю структуру можна спостерігати в прикладних рамках (принаймні Rails та Symfony).

Це спосіб зберегти lib/ srcструктуру недоторканою для розробників додатків, додаючи при цьому інший рівень відстані, принесений використанням фреймворку: vendorпапка фактично містить бібліотеки рамки, залишаючи libпапку для бібліотек, що входять до програми, та srcдля її джерела файли.

Це "більш віддалений" lib, життєво важливий, оскільки без фреймворку додаток марний, але його не торкається розробник програми: це бібліотеки постачальника фреймворків .

— MattiSG
джерело

10

У випадку чогось типу Symfony lib- це код програми (тобто написаний розробниками) і vendorє стороннім кодом. Подумайте про це як lib - це те, що srcзазвичай є папкою, а постачальник - lib. Я зазвичай бачу цей стиль у PHP, оскільки ви виділяєте шаблони HTML від фактичних класів.

— Уейн Моліна
джерело

2

Із керівництва по трубопроводі рейки :

app/assets призначений для активів, які належать додатку, таких як власні зображення, файли JavaScript або таблиці стилів.
lib/assets - це код вашої власної бібліотеки, який насправді не входить у сферу застосування або для тих бібліотек, які спільно використовуються між програмами.
vendor/assets призначений для активів, які належать стороннім організаціям, наприклад, код для плагінів JavaScript та фреймворки CSS.

Я знаю, що це не специфічне для Rails питання, але пояснення добре і зрозуміло і, ймовірно, поширюється на інші рамки / структури проектів.

— Чіко Карвальо
джерело