Go отличается от многих других языков тем, что для него существует широкий спектр методов и инструментов управления зависимостями. Подход, одобренный командой Go, включает в себя создание зависимостей в папке проекта и изменение операторов импорта для поддержки нового местоположения.
Godep работает не так, как одобренный подход… Вместо того, чтобы требовать внесения изменений в исходный код для поддержки пути импортированного поставщика, GOPATH модифицируется для использования папки Vendored. Это полезно, так как один и тот же код будет работать как в среде Godep, так и в автономной среде, используя go get для настройки GOPATH . Существуют и другие методы и инструменты управления зависимостями, поэтому обязательно ознакомьтесь с ними и выберите один, подходящий для вашего проекта или организации.
Основные инструкции по использованию смотрите в документации Godep . Основываясь на своем опыте работы с Godep, я дам вам краткий обзор преимуществ и недостатков его использования, а также несколько рекомендаций.
Как работает Годеп
Команда godep save скопирует все импортированные пакеты целиком из вашей текущей GOPATH в папку рабочего пространства производителя в ./Godeps/_workspace . Список этих пакетов будет храниться с соответствующей информацией о версии в главном файле Godeps / Godeps.json . Это сделано не только для пакетов, которые ваш проект импортирует напрямую, но и для любых пакетов, импортированных вашими зависимостями — по сути, всего, что требуется для сборки вашего проекта. Вы должны добавить всю эту папку SCM, и она никогда не должна изменяться вручную.
Использовать Godep так же просто, как добавить обычные команды Go, такие как go test или go build, с помощью команды godep . При этом используется временно расширенная GOPATH, которая устанавливает приоритет для каталога поставщиков Godep.
|
1
2
3
|
$ godep save ./… # saves your GOPATH to the Godep folder$ godep go build ./… # builds using the Godep vendored dependencies$ godep go test ./… # tests using the Godep vendored dependencies |
Отсюда, если вы внесете изменения в GOPATH , ваш проект будет изолирован.
|
1
2
3
|
$ go get -u github.com/golang/protobuf/… # update a dependency$ go build ./… # build using standard GOPATH$ godep go build ./… # build using Godep vendored version |
обновление godep против сохранения godep
Есть два способа применить изменения к вашей папке Godep. Понимание правильных случаев использования каждого из них сэкономит вам огромное количество времени и разочарований. godep save и godep update работают по-разному и изменяют ваш Godep по-разному. Здесь нужно помнить, что если у вас есть сомнения, используйте godep save .
Обновление godep принимает определенный пакет зависимостей и обновляет экземпляр этого пакета, выпущенный продавцом, с версией в вашей GOPATH . Это обновит файлы с изменениями, добавит новые файлы, удалит старые и обновит версию SHA, указанную в файле Godeps.json.
|
1
2
|
$ go get -u github.com/golang/protobuf/…$ godep update github.com/golang/protobuf/… |
Это не будет добавлять или удалять подпакеты из управления зависимостями, а также не будет рекурсивно обновлять любые другие зависимости. В файле Godeps.json перечислены только ранее импортированные пакеты, и обновлены только те, которые перечислены.
Обновление всего пакета обновит любые ссылки на подпакеты; однако новые пакеты не будут добавлены, а старые не будут удалены. Аналогично, если обновление вашей зависимости зависит от другого изменения в другом месте вашего стека зависимостей, вы можете столкнуться с проблемами. Обновление godep касается только пакетов, перечисленных в Godeps.json, которые соответствуют предоставленному шаблону пакета.
Напротив, godep save применяет всю соответствующую GOPATH к папке Godeps и будет добавлять / удалять пакеты по мере необходимости. Поскольку он основан на вашей GOPATH , godep save также может проверять ошибки сборки и неочищенные репозитории перед применением изменений, обеспечивая согласованность зависимостей.
Учитывая опасность использования godep update (отсутствие пакетов и зависимостей), гораздо безопаснее использовать godep save . Единственная ситуация, когда безопасно использовать обновление godep, это когда оба эти условия выполнены:
- Нет необходимости обновлять зависимости вашей целевой зависимости.
- Нет импорта были добавлены или удалены из вашей целевой зависимости.
Если зависимость является внешней по отношению к вашей организации, может быть трудно определить, какие изменения происходят, поэтому безопаснее никогда не использовать ** godep update` на сторонних продуктах.
Предостережения о работе с Годепом
Помимо знания основных команд, которые можно использовать с Godep, есть несколько ошибок.
«Знать основные команды с Godep, а также уловки» через @codeship
Годеп может расходиться по проектам
В ситуациях, когда зависимость имеет версии из нескольких источников, она может быть легко представлена в разных версиях в одной и той же среде Godep.
Рассмотрим случай, когда внутренняя кодовая база ProjectA перечисляет ProjectB и ThirdPartyA как зависимости. И ProjectB, и ThirdPartyA перечисляют ThirdPartyB как зависимость. Если ThirdPartyA когда-либо обновляется, чтобы требовать новую версию ThirdPartyB, в то время как ProjectB продолжает ссылаться на более старую версию ThirdPartyB, какую версию ProjectA перечисляет в Godeps?
|
1
2
3
4
5
|
ProjectA ├-- ProjectB | └-- ThirdPartyB ├-- ThirdPartyA | └-- ThirdPartyB |
Ответ прост.
Godep не имеет внутреннего механизма разрешения конфликтов и не разрешает требования зависимостей Godep. Решение о том, какую версию использовать, остается за разработчиком; в этом случае ProjectA будет использовать ту версию ThirdPartyB, которая была в последний раз установлена в Godep. Поскольку последняя запись была из обновления ThirdPartyA, ProjectA будет ссылаться на более новую версию. Любой код из ProjectB будет ссылаться на более новую версию при загрузке в качестве зависимости.
Это тонкий момент, но он подчеркивает необходимость соблюдать осторожность при обновлении зависимостей, а также необходимость синхронизации всех изменений версий зависимостей между проектами. Ошибки компиляции будут обнаружены при создании ProjectA, но едва заметные изменения в поведении могут быть обнаружены позже.
Поэтому обновление зависимостей должно применяться ко всем проектам одновременно. Подумайте об обновлении зависимостей с помощью зацикленного скрипта, применяя изменения ко всем вашим кодам одновременно.
|
01
02
03
04
05
06
07
08
09
10
|
for project in projects cd workspace/project git checkout master && git pull godep restore go get -u ThirdPartyB/… godep save ./… git checkout -b “updating-godeps” git commit ./Godeps -m “Updating Godeps” git push origin updating-godepsend |
В тех случаях, когда нескольким внутренним проектам требуется синхронизированная версия зависимости, гораздо проще использовать разветвленную версию зависимости и продвигать управление зависимостями до развилки, поддерживаемого вашей организацией. Этот форк становится центральным элементом управления версиями этой зависимости. Однако более вероятно, что обновление этой зависимости вызовет критические критические изменения в нескольких проектах.
Чтобы получить список различных методов и инструментов управления зависимостями для Go, ознакомьтесь с документами Golang по этому вопросу .
Годеп все еще использует ваш местный GOPATH
Несмотря на то, что Godep предоставляет версионный экземпляр GOPATH , он все еще использует ваш оригинальный GOPATH . Поставленное рабочее пространство проверяется на наличие пакета перед вашей основной GOPATH . Обычно это не вызывает проблем, но в некоторых случаях это может быть проблематично.
Поскольку на ваш основной GOPATH ссылаются, недостающие зависимости могут быть обнаружены только позже в цикле разработки. Любой пакет, отсутствующий в Godep, скорее всего, присутствует в вашей GOPATH ; этот беспроблемный запасной вариант затрудняет определение того, какую версию зависимости команда использует. Из-за этой составной GOPATH ошибки сборки могут появляться, когда версии зависимостей несовместимы. Лучший способ избежать этой проблемы и своевременно отловить недостающие зависимости — это создать одноразовую GOPATH или контейнер.
Когда использовать Godep
Не каждый проект может требовать широкого контроля зависимостей, как это предусмотрено Godep.
В отличие от импорта на основе пути импорта, Godep предоставляет полный набор зависимостей независимо от конкретного желания их версии. Это означает, что никакие зависимости никогда не будут обновлены, если они не будут изменены явно, сначала через GOPATH, а затем через Godep.
Если ваша организация имеет большое количество общих зависимостей между различными проектами, вы можете рассмотреть возможность использования раздвоенной модели зависимостей. Godep предоставляет локально управляемую, настраиваемую систему управления зависимостями. При осторожном использовании эта система может поддерживать высокодоверные и воспроизводимые сборки, особенно в средах с изменяющимся сопротивлением, с несколькими общими зависимостями.
| Ссылка: | Управление зависимостями godep in Go от нашего партнера по JCG Брендана Фосберри в блоге Codeship Blog . |