Модули в Golang: команды с поддержкой модулей, go mod vendor

Использование:

go mod vendor [-e] [-v]

Команда go mod vendor создает каталог с именем vendor в корневом каталоге основного модуля, который содержит копии всех пакетов, необходимых для поддержки сборки и тестирования пакетов в основном модуле. Пакеты, которые импортируются только тестами пакетов вне основного модуля, не включаются. Как и в случае с go mod tidy и другими командами модуля, ограничения сборки, за исключением игнорирования, не учитываются при создании каталога vendor.

Когда вендоринг включен, команда go будет загружать пакеты из каталога vendor вместо того, чтобы загружать модули из их источников в кеш модулей и использовать пакеты, которые были загружены копиями.

go mod vendor также создает файл vendor/modules.txt, содержащий список поставленных пакетов и версий модулей, из которых они были скопированы. Когда вендоринг включен, этот манифест используется в качестве источника информации о версии модуля, о чем сообщает go list -m и go version -m. Когда команда go читает vendor/modules.txt, она проверяет, соответствуют ли версии модуля go.mod. Если go.mod изменился с момента создания vendor/modules.txt, необходимо снова запустить go.mod vendor.

Обратите внимание, что go mod vendor удаляет каталог vendor, если он существует, перед его повторным построением. Не следует вносить локальные изменения в поставленные пакеты. Команда go не проверяет, что пакеты в каталоге vendor не были изменены, но можно проверить целостность каталога vendor, запустив go mod vendor и проверив, что никаких изменений не было.

Флаг -e (добавлен в Go 1.16) заставляет go mod vendor попытаться продолжить, несмотря на ошибки, обнаруженные при загрузке пакетов.

Флаг -v заставляет go mod vendor печатать имена поставленных модулей и пакетов в стандартную ошибку.

---

Читайте также:

• Модули в Golang: команды с поддержкой модулей, go mod graph
• Модули в Golang: команды с поддержкой модулей, go mod init
• Модули в Golang: команды с поддержкой модулей, go mod tidy

Канал в Телеграм

Модули в Golang: команды с поддержкой модулей, вендоринг

При использовании модулей команда go обычно удовлетворяет зависимости, загружая модули из их источников в кеш модулей, а затем загружая пакеты из этих загруженных копий. Вендоринг может использоваться для обеспечения взаимодействия со старыми версиями Go или для того, чтобы все файлы, используемые для сборки, хранились в едином дереве файлов.

Команда go mod vendor создает каталог с именем vendor в корневом каталоге основного модуля (main module), содержащий копии всех пакетов, необходимых для сборки и тестирования пакетов в основном модуле. Пакеты, которые импортируются только тестами пакетов вне основного модуля, не включаются. Как и в случае с go mod tidy и другими командами модуля, ограничения сборки, за исключением игнорирования, не учитываются при создании каталога vendor.

go mod vendor также создает файл vendor/modules.txt, содержащий список поставленных пакетов и версий модулей, из которых они были скопированы. Когда вендоринг включен, этот манифест используется в качестве источника информации о версии модуля, о чем сообщает go list -m и go version -m. Когда команда go читает vendor/modules.txt, она проверяет, соответствуют ли версии модуля go.mod. Если go.mod был изменен с момента создания vendor/modules.txt, команда go сообщит об ошибке. go mod vendor следует запустить снова, чтобы обновить каталог vendor.

Если каталог vendor присутствует в корневом каталоге основного модуля, он будет использоваться автоматически, если версия go в файле go.mod основного модуля 1.14 или выше. Чтобы явно включить вендоринг, вызовите команду go с флагом -mod=vendor. Чтобы отключить вендоринг, используйте флаг -mod=mod.

Когда вендоринг включен, команды сборки, такие как go build и go test, загружают пакеты из каталога vendor вместо доступа к сети или локальному кешу модуля. Команда go list -m выводит информацию только о модулях, перечисленных в go.mod. Команды go mod, такие как go mod download и go mod tidy, не работают по-другому, когда включен вендоринг, и все равно будут загружать модули и обращаться к кешу модулей. go get также не работает по-другому, когда включен вендоринг.

В отличие от вендоринга в GOPATH, команда go игнорирует каталоги поставщиков (vendor directories) в местах, отличных от корневого каталога основного модуля.

---

Читайте также:

• Модули в Golang: минимальная совместимость модулей
• Модули в Golang: команды с поддержкой модулей
• Модули в Golang: команды с поддержкой модулей, команды сборки

Канал в Телеграм

Модули и вендоринг в Golang

При использовании модулей команда go полностью игнорирует каталоги поставщиков (vendor directories).

По умолчанию команда go удовлетворяет зависимости, загружая модули из их источников и используя эти загруженные копии (после проверки, как описано в предыдущем посте). Чтобы разрешить взаимодействие со старыми версиями Go или чтобы все файлы, используемые для сборки, хранились вместе в одном дереве файлов, go mod vendor создает каталог с именем vendor в корневом каталоге основного модуля и сохраняет там все пакеты из зависимых модулей, необходимые для поддержки сборок и тестов пакетов в основном модуле.

Для сборки с использованием каталога поставщиков верхнего уровня основного модуля для удовлетворения зависимостей (отключение использования обычных сетевых источников и локальных кэшей) используйте 'go build -mod=vendor'. Обратите внимание, что используется только каталог поставщика верхнего уровня основного модуля; каталоги поставщиков в других местах по-прежнему игнорируются.

---

Читайте также:

• Запросы модулей (module query) в Golang
• Определение модуля, файл go.mod
• Псевдо-версии модулей в Golang

Каталоги поставщиков (Vendor Directories) в Golang

В Go 1.6 включена поддержка использования локальных копий внешних зависимостей для удовлетворения импорта этих зависимостей, часто называемого вендорингом.

Код под каталогом с именем vendor импортируется только кодом в дереве каталогов, корнем которого является родительский элемент vendor, и только с использованием пути импорта, в котором префикс не указан, вплоть до элемента vendor.

Вот пример из предыдущего поста, но с "internal" каталогом, переименованным в "vendor" и добавленным новым каталогом foo/vendor/crash/bang:

/home/user/go/
    src/
        crash/
            bang/              (go код в пакете bang)
                b.go
        foo/                   (go код в пакете foo)
            f.go
            bar/               (go код в пакете bar)
                x.go
            vendor/
                crash/
                    bang/      (go код в пакете bang)
                        b.go
                baz/           (go код в пакете baz)
                    z.go
            quux/              (go код в пакете main)
                y.go

Применяются те же правила видимости, что и для internal, но код в z.go импортируется как "baz", а не как "foo/vendor/baz".

Код в vendor каталогах, находящихся глубже в дереве исходного кода затеняет код в вышестоящих каталогах. В поддереве с корнем в foo импорт "crash/bang" разрешается в "foo/vendor/crash/bang", а не в "crash/bang" верхнего уровня.

Код в каталогах поставщиков не подлежит проверке пути импорта (см. go help importpath).

Когда 'go get' проверяет или обновляет git-репозиторий, теперь он также обновляет подмодули.

Каталоги поставщиков не влияют на размещение новых репозиториев, впервые проверяемых с помощью функции 'go get': они всегда помещаются в основной GOPATH, а не в поддерево поставщиков.

---

Читайте также:

• Инструмент go, команды
• Go модули
• Команды go: go mod, обслуживание модуля