Подтвердить что ты не робот

Как использовать поставщика в Go 1.6?

Сначала я прочитал этот ответ: Vendoring in Go 1.6, затем я использую его в качестве примера.

Мой гопат GOPATH="/Users/thinkerou/xyz/", а следующие:

[email protected]:~/xyz/src/ou$ pwd
/Users/baidu/xyz/src/ou
[email protected]:~/xyz/src/ou$ ls
main.go vendor

Теперь я использую go get, затем становится следующим:

[email protected]:~/xyz/src/ou$ ls
main.go vendor
[email protected]:~/xyz/src/ou$ cd vendor/
[email protected]:~/xyz/src/ou/vendor$ ls
vendor.json
[email protected]:~/xyz/src/ou/vendor$ cd ../..
[email protected]:~/xyz/src$ ls
github.com ou
[email protected]:~/xyz/src$ cd github.com/
[email protected]:~/xyz/src/github.com$ ls
zenazn

vendor.json:

{
    "comment": "",
    "package": [
        {
            "path": "github.com/zenazn/goji"
        }
    ]
}

тогда я должен использовать какие команды? почему не использовать vendor? Моя версия - 1.6.2.

4b9b3361

ОТВЕТЫ

Ответ 1

С Go1.6, когда вы читаете, вендинг встроен. Что это значит? Помните только одно:

При использовании инструментов go, таких как go build или go run, они сначала проверяют, находятся ли зависимости в ./vendor/. Если да, используйте его. Если нет, вернитесь в каталог $GOPATH/src/.

Фактические "пути поиска" в Go 1.6 имеют порядок:

./vendor/github.com/zenazn/goji
$GOPATH/src/github.com/zenazn/goji
$GOROOT/src/github.com/zenazn/goji

С учетом сказанного go get продолжит установку в вас $GOPATH/src; и go install будет установлен в $GOPATH/bin для двоичных файлов или $GOPATH/pkg для кэширования пакетов.

Итак, как я могу использовать. /vendor?!?!

Хе-хе, вооруженный знанием выше, это довольно просто:

mkdir -p $GOPATH/src/ou/vendor/github.com/zenazn/goji
cp -r $GOPATH/src/github.com/zenazn/goji/ $GOPATH/src/ou/vendor/github.com/zenazn/goji

Короче говоря, чтобы использовать вендование, вы копируете файлы, используя тот же самый путь github.com/zenazn/goji, в свой директор поставщика.

Теперь утилита go build/install/run увидит и использует вашу папку поставщика.

Более простой способ вместо копирования всего вручную

Вместо поиска и копирования всех 25 продуктов-поставщиков, управления их версиями, обновления других проектов и т.д.... Лучше использовать инструмент управления зависимостями. Есть много вещей, и небольшой поиск в Google укажет вам несколько.

Позвольте мне упомянуть два, которые работают с папкой поставщика и не сражаются с вами:

  • godep
  • govendor

Вкратце, эти инструменты проведут проверку вашего кода ou, найдут удаленные зависимости и скопируют их из вашего $GOPATH/src в ваш каталог $GOPATH/src/ou/vendor (фактически, независимо от того, в каком текущем каталоге вы находитесь, когда вы их запускаете).

Например, скажем, что все ваши зависимости установлены и нормально работают в вашем проекте $GOPATH/src/ou/, используя обычную установку ваших зависимостей GOPATH/src/github. Ваш проект работает, и ваши тесты проверяют, что все работает с точной версией ваших репозиториев. Например, с помощью Godep вы запустите это из корневой папки проекта $GOPATH/src/ou/:

godep save ./...

Это скопирует все зависимости, которые ваш проект использует в вашей папке. /vendor.

Городе очень важен самый популярный. У них есть собственный канал Slack в группе Gopher Slack. И это тот, который я использую в своих командах.

Govendor - еще одна альтернатива, которую я прочитал, имеет приятную синхронизацию. Я не использовал его, хотя.

Использование инструмента управления зависимостями

Это чисто мнение, и я уверен, что ненавистники будут снижать ставку... Но поскольку мне нужно закончить мой пост в блоге по этому вопросу, позвольте мне упомянуть здесь, что большинство людей слишком беспокоиться о управлении репутацией в Go.

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

Используйте управление зависимостями для этих целей.

Но существует чрезмерное использование простых проектов, которые блокируют огромное количество зависимостей, когда на самом деле...

Вам может потребоваться только заблокировать только 1 зависимости; в противном случае вы хотите получить последнюю версию драйверов MySQL и фреймворков тестирования для исправления ошибок.

Здесь можно реально использовать папку ./vendor/, отличную от инструментов управления зависимостями: вам нужно будет только скопировать это репо, в которое вы должны быть заблокированы.

Вы выборочно выбираете одно неподходящее репо и помещаете его в свою папку. /vendor/. Делая это, вы говорите своим потребителям:

Эй, это одно репо должно быть сдержано в этой ревизии. Все остальные в порядке и используют последние из них и часто обновляют с помощью go get -u ./...; но это не удалось с более новыми версиями, поэтому не обновляйте это одно репо.

Но если вы полностью сохраняете все свои зависимости с помощью инструмента управления зависимостями, вы в основном говорите своим потребителям:

Может быть или не быть проблемой с одним или несколькими репозициями из 20 в папке поставщика. Вы можете или не сможете обновить их. Вы можете или не сможете получить последний драйвер MySQL. Мы просто не знаем, что может или не может быть причиной проблем и просто заблокировано чем-то, что работало в то время, когда я бежал godep save. Так что да, обновляйся на свой страх и риск.

Лично я столкнулся с этим несколько раз. Зависимость обновлялась с изменением разбиения, и у нас есть десятки зависимых от него репозиториев. Приобретение только одного репо в /vendor позволяет нам использовать эту версию зависимости, а go get ./... продолжает нормально работать для всех остальных репозиториев, чтобы получить последнюю версию. Мы запускаем последние исправления ошибок в PSQL и MySQL и другие (для них есть постоянные исправления!) И т.д.