Ответ
Директория vendor в Go — это механизм для изоляции зависимостей проекта. Она содержит точные копии всех сторонних библиотек, от которых зависит проект. Когда эта директория присутствует, компилятор Go по умолчанию использует пакеты из неё, а не из глобального кэша модулей.
Это обеспечивает воспроизводимость сборок, так как проект становится полностью самодостаточным и не зависит от доступности внешних репозиториев или изменений в них.
Как это работает:
- Вы управляете зависимостями в файле
go.mod. - Выполняете команду
go mod vendor. - Go создаёт директорию
vendorи копирует в неё исходный код всех зависимостей изgo.mod.
Пример структуры проекта:
myproject/
├── go.mod
├── go.sum
├── main.go
└── vendor/ <-- Создается командой `go mod vendor`
├── github.com/
├── golang.org/
└── ...
Основные команды:
go mod vendor— создаёт или обновляет директориюvendor.go build -mod=vendor— принудительно использует зависимости изvendor(начиная с Go 1.14, этот флаг часто не требуется, если директорияvendorсуществует).
Преимущества:
- Изоляция и воспроизводимость: Сборка не зависит от внешних факторов и всегда будет использовать одни и те же версии кода.
- Работа в оффлайн-режиме: Проект можно собрать без доступа к интернету.
- Контроль: Полный контроль над кодом зависимостей, который можно даже аудировать или модифицировать при необходимости.
Недостатки:
- Размер репозитория: Директория
vendorможет значительно увеличивать размер репозитория. - Ручное обновление: Требуется не забывать выполнять
go mod vendorпосле каждого изменения вgo.mod.
Ответ 18+ 🔞
А, директория vendor в Go, ну это ж классика, блядь! Слушай сюда, представь себе такую картину: ты пишешь свой проект, подключаешь кучу библиотек от левых дядек с GitHub, и всё вроде летает. А потом раз — и один из этих дядек взял и удалил свою библиотеку, или хуже того, обновил её так, что у тебя всё сломалось. Пиздец, да? Вот чтобы такого не было, умные люди придумали эту самую vendor-директорию.
По сути, это твой личный склад, твой бункер, куда ты, как запасливый хомяк, сносишь точные копии всех этих сторонних библиотек, которыми пользуешься. И когда эта папка есть, Go, такой умный, перестаёт шариться по интернетам и лезть в свой глобальный кэш, а тупо берет всё с этого склада. Проект становится самодостаточной хуевой крепостью, которую можно собрать где угодно: хоть на сервере без интернета, хоть через десять лет. Это и есть та самая воспроизводимость сборок, о которой все так заливаются.
Как этот цирк работает, ёпта:
- У тебя есть файл
go.mod— это типа список покупок, где указано, какие библиотеки и в каких версиях тебе нужны. - Ты даёшь команду
go mod vendor. Go, такой работяга, идёт, закупает по этому списку всё необходимое и складирует у тебя в проекте, в папкуvendor. - Всё. Теперь у тебя свой огород.
Вот как это выглядит вживую, блядь:
мой_проект_гениальный/
├── go.mod (список)
├── go.sum (чек)
├── main.go (твой код, святое)
└── vendor/ <-- Вот он, склад, созданный по команде!
├── github.com/какой-то-левак/
├── golang.org/более-менее-официальный/
└── ... (и так далее, овердохуища папок)
Что ты с этим делаешь обычно:
go mod vendor— главная команда. "Закупиться по списку" или "пополнить склад".go build -mod=vendor— сказать Go: "Э, дружок, не умничай, бери всё со склада, а не ищи где попало". Хотя в новых версиях Go, если видит папкуvendor, часто и так всё понимает, хитрая жопа.
Чем это офигенно:
- Изоляция, ёбана! Твой проект теперь не зависит от того, удалил ли какой-то пидарас свой репозиторий или накосячил с обновлением. Всё лежит у тебя.
- Оффлайн — не приговор. Интернет пропал? Да похуй. Собирай проект хоть в бункере.
- Полный контроль. Хочешь — загляни в код библиотеки, которую используешь. Хочешь — временно поправь какую-нибудь строку у себя локально (только потом не забудь, что правил, а то будет мудя).
Чем это сосёт:
- Размер репозитория взлетает, как хуй с горы. Папка
vendorможет весить десятки мегабайт. Git-то всё это хранить будет. - Ручное управление. Добавил новую библиотеку в
go.mod? Не забудь выполнитьgo mod vendor, а то склад не обновится. Сам от себя охуеешь потом, когда сборка сломается.
Короче, инструмент на все случаи жизни. Для продакшена — часто must have, чтобы не было сюрпризов. Для маленьких пет-проектов — иногда overkill. Решай сам, но принцип понимать надо, а то будешь как Герасим — "Муму-муму", а оно не работает.