Цикл статей, перепечатанный ранее:50 ям, которые нужно избегать Голангу, в целом объем чтения довольно большой. В сегодняшней статье поговорим об инструменте управления пакетами зависимостей Go.
задний план
Каждый язык имеет свою собственную экосистему зависимостей.Когда мы используем язык Java, мы используем Maven или Gradle для управления зависимостями пакетов. Одной из проблем, которую многие разработчики критиковали в раннем Go, было управление зависимостями. До выпуска версии Golang 1.5 можно было установить только несколькоGOPATHспособ решения этой проблемы, например: оба моих проекта зависят от Beego, но проект A зависит от Beego 1.1, проект B зависит от Beego 1.7, я должен установить дваGOPATHотличать, и при переключении проектовGOPATHПереключаться очень больно. В версии Golang 1.5 поддержка, кромеGOROOTиGOPATHУправление внешними зависимостями: поставщик, официальная вики рекомендует различные инструменты управления пакетами, поддерживающие эту функцию, такие как: Godep, gv, gvt, glide, govendor и официальный dep.
Подготовка окружающей среды
Установить Go
У автора система Mac.Существует множество способов установки Go.Вы можете установить go через brew,скачать исходный код и установить go.
Настройте расположение GOPATH и GOBIN в bash_profile:
GOROOT=/usr/local/go
export GOPATH=/Users/user/aoho/go-workspace
export GOBIN=$GOPATH/bin
export PATH=$PATH:$GOBIN:$GOROOT/bin
После завершения установки просмотрите переменные окружения go:go env.
GOARCH="amd64"
GOBIN="/usr/local/go/bin/go"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/user/aoho/go-workspace"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/st/gkm45qzd2tv8mc32my38_n_00000gp/T/go-build646095787=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
Go-версия:go version go1.9.3 darwin/amd64.
ГОПАТ и ГОРУТ
GOROOT не нужно устанавливать. По умолчанию go будет установлен в /usr/local/go, но также разрешены пользовательские места установки.Цель GOROOT — сообщить go о текущем месте установки.При компиляции перейдите в GOROOT, чтобы найти системную библиотеку SDK.
Как показано выше, автор использует адрес установки по умолчанию, или вы можете использоватьexport GOROOT=$HOME/go1.9.3указано.
GOPATH должен быть установлен, но это не фиксировано. Цель GOPATH — указать, где искать, когда нужен код. Обратите внимание на приведенный здесь код, включая этот проект и код, ссылающийся на внешние проекты. GOPATH можно сбрасывать из проекта в проект.
В GOPATH будет три каталога: src, bin и pkg.
- каталог src: где go ищет код при компиляции;
- каталог bin: когда вы получите этот инструмент bin, место назначения для загрузки двоичного файла;
- Каталог pkg: где хранятся скомпилированные файлы lib.
управление пакетами
Как упоминалось в предыдущем разделе, зависимый код переходит в$GOPATHНайдите указанное место, эта часть кода может быть этим проектом или проектом с внешней ссылкой. Оба случая описаны по очереди ниже.
Управление внутренними зависимостями
Например, введение авторского примера route_auth.go:
import (
"gwp/Chapter_2_Go_ChitChat/chitchat/data"
"net/http"
)
route_auth.go должен ссылаться на data/user.go Структура проекта выглядит следующим образом:
При компиляции он попадет в$GOPATH/src/каталог, чтобы найти требуемый код, так что пока data/user.go выше находится в$GOPATH/src/gwp/Chapter_2_Go_ChitChat/chitchat/dataВнутри его можно найти, когда go компилируется.
Управление внешними зависимостями
Для управления внешними зависимостями вначале go не использовал maven для управления зависимыми пакетами и версиями пакетов, такими как java, а напрямую использовал GOPATH для управления внешними зависимостями.
GOPATH для управления внешними зависимостями
go позволяет импортировать код из разных кодовых баз,например, github.com, k8s.io, golang.org и т. д.; для кода, который необходимо импортировать, вы можете использовать команду go get, чтобы удалить его и поместить в каталог, соответствующий GOPATH. Напримерgo get github.com/globalsign/mgo, будут загружены в$GOPATH/src/github.com/globalsign/mgoидти, когда другие предметы вimport github.com/globalsign/mgoВы также можете найти соответствующий код.
Видя это я понимаю что для go не особо важно внутренний у вас код или внешний.Короче он в GOPATH.Путь любого пакета импорта начинается с GOPATH разница только во внутреннем Зависимые пакеты пишутся самими разработчиками, а внешне зависимые пакеты получаются с помощью goget. Недостатки собственного управления пакетами языка Go:
- Платформы, которые могут получить исходный код, очень ограничены, и большинство из них полагаются наgithub.com
- Версию нельзя различить, поэтому разработчик использует последнее имя пакета в качестве разделения версии.
- Список/отношения зависимостей не могут быть сохранены локально, вам нужно найти все зависимые пакеты, а затем получить их один за другим.
- Можно полагаться только на локальное глобальное хранилище (GOPATH/GOROOT), нельзя разместить библиотеку на локальном хранилище ($PROJECT_HOME/vendor).
vendor
Использование GOPATH для решения проблем импорта go было указано в разделе выше. Чтобы решить эту проблему, go ввел атрибут поставщика в версии 1.5 (по умолчанию отключен, вам необходимо установить переменную среды go GO15VENDOREXPERIMENT=1), а атрибут поставщика включен по умолчанию в версии 1.6.
Проще говоря, атрибут поставщика заключается в том, чтобы разрешить компиляцию кода сначала из каталога поставщика в корневом каталоге исходного дерева проекта (это можно понимать как сокращение GOPATH один раз), и если он есть в поставщике, он больше не будет обращаться к GOPATH, чтобы найти его.
Возьмем, к примеру, kube-keepalived-vip.Проект вызовет библиотеку k8s.io/kubernetes (Client), но если вы используете код kubernetes версии 1.5 для компиляции keepalived, он не скомпилируется. Код изменился в версии 1.5, и этот Клиент больше не доступен. Это то, что я сказал, прежде чем полагаться на GOPATH для решения goПроблема, вызванная импортом, заключается в том, что код неверен.
Проект kube-keepalived-vip решает эту проблему с каталогом vendor: проект копирует все зависимые пакеты в каталог vendor.Для тех, кому нужно компилировать проект, достаточно клонировать код с github в$GOPATH/srcПосле этого можно переходить к сборке (учтите, что проект kube-keepalived-vip необходимо скопировать в$GOPATH/srcкаталог, в противном случае go будет игнорировать каталог поставщика и по-прежнему идти$GOPATH/srcнайти пакеты зависимостей).
Некоторые проблемы решает вышеуказанный производитель, но возникают новые проблемы:
- Пакеты зависимостей в каталоге поставщика не имеют информации о версии. Таким образом, пакет зависимостей отделен от управления версиями, и будет немного сложно обновить и отследить проблему.
- Как легко получить, от каких пакетов зависит этот проект, и легко скопировать их в каталог поставщика? Нереально полагаться на людей.
Чтобы решить эти проблемы, сообщество открытого исходного кода разработало ряд инструментов управления, основанных на вендоре, наиболее распространенными из которых являются godep, govendor glide и т. д. Go официально выпустил dep.
godep
godep — это инструмент управления для разрешения зависимостей пакетов.Принцип заключается в сканировании и записи информации о контроле версий и добавлении оболочки перед командой go для управления зависимостями. Более ранние версии godep не зависели от производителя, поэтому требования к версии для go были свободными, и версии до go 1.5 также можно было использовать, но поведение было другим. После запуска вендора, godep тоже изменился на вендор. godep рекомендуется использовать после golang 1.6, а godep зависит от вендора.
Есть много пользователей godep.Многие проекты go, такие как docker, kubernetes, coreos и т. д., используют godep для управления своими зависимостями.Конечно, причина может заключаться в том, что в первые дни не было доступных инструментов.
go get -u -v github.com/tools/godep
Установить с помощью приведенной выше команды, после успешной установки, в$GOPATHВ каталоге bin будет исполняемый бинарный файл godep, и команды, выполняемые позже, будут его использовать.Рекомендуется добавить этот каталог в глобальную переменную окружения.
скомпилировать и запустить
Поскольку команда go переходит непосредственно в каталог GOPATH для поиска сторонних библиотек и поддерживает компиляцию поставщика после версии 1.6, а зависимые библиотеки, загружаемые godep, помещаются в каталог Godeps/workspace, но это не влияет на дальнейшее использование зависит от каталога GOPATH, так же как и сами сторонние инструменты не конфликтуют. Так что используйте:
godep go build main.go
Команда go в godep состоит в том, чтобы добавить оболочку к исходной команде go и выполнить ее.godep go, каталог рабочей области текущего проекта будет добавлен в переменную GOPATH.
Проверить зависимости
Если вы хотите добавить новый пакет зависимостей:
- бегать
go get github.com/globalsign/mgo - в коде
import github.com/globalsign/mgo
Проект написан, пользуйтесьGOPATHКогда тест пакета зависимостей пройдет успешно, выполните:
godep save
Приведенная выше команда автоматически просканирует все внешние зависимые библиотеки (несистемные библиотеки), импортированные в пакет, которому принадлежит текущий каталог, и загрузит все зависимые библиотеки в текущий проект для создания файлов.Godeps/Godeps.jsonдокумент.
godep saveКогда godep копирует все зависимые коды пакетов из пути GOPATH в каталог Godeps и удаляет каталог управления кодом. Это в основном для поддержки ряда операций инструмента godep go, особенно после того, как git клонирует кодовую базу, обычно используется godep go install xxx для завершения компиляции, что может в определенной степени облегчить строгий путь кода и управление пакетами golang. . При отсутствии файла Godeps мод сборки зависит от папки поставщика. Если вы используете стороннюю библиотеку для разработки зависимостей и вам необходимо использовать определенную версию, полностью отправьте папки Godeps и vendor.
Пакеты зависимостей будут обновлены Как обновить зависимые пакеты? Это можно сделать с помощью следующей команды.
- бегать
go get -u github.com/globalsign/mgo - бегать
godep update github.com/globalsign/mgo
Восстановление зависимостей по запросу
по командеgodep restoreСинхронизируйте зависимые библиотеки.Если загруженный проект содержит только файл Godeps.json и не содержит третьей библиотеки, вы можете использовать команду godep restore для загрузки всех зависимых библиотек в$GOPATH\srcдля развития.
Когда будет выполнено восстановление godep, godep будет следовать списку в Godeps/Godeps.json и выполнить go get -d -v, в свою очередь, чтобы загрузить соответствующий пакет зависимостей по пути GOPATH.
govendor
govendor вышел после vendor и имеет больше функций, чем godep, но решение основной проблемы в основном такое же. Этот инструмент копирует внешние пакеты, от которых зависит проект, в каталог поставщика в рамках проекта и записывает версию зависимого пакета через файл vendor.json, что удобно для пользователей, использующих относительно стабильные зависимости.
go get -u github.com/kardianos/govendor
Приведенная выше команда может установить govendor. Когда govendor создает каталог поставщика, требуются 2 команды:
- govendor init генерирует vendor/vendor.json, на данный момент в файле находится информация только об этом проекте
- govendor добавьте +external update vendor/vendor.json и скопируйте код из GOPATH в каталог поставщика. Управляющий также может напрямую указать зависимую версию пакета, чтобы получить пакет.
Существуют в основном следующие типы зависимостей для govendor:
Шаги для использования
Перейдите в корневой каталог проекта.
# 创建 vendor 文件夹和 vendor.json 文件
govendor init
# 从 $GOPATH 中添加依赖包，会加到 vendor.json
govendor add +external
# 列出已经存在的依赖包
govendor list
# 找出使用的对应包
govendor list -v fmt
# 拉取指定版本的包
govendor fetch golang.org/x/net/context@a4bbce9fcae005b22ae5443f6af064d80a6f5a55
govendor fetch golang.org/x/net/context@v1 # Get latest v1.*.* tag or branch.
govendor fetch golang.org/x/net/context@=v1 # Get the tag or branch named "v1".
По сравнению с вышеперечисленными инструментами у govendor больше функций.
Суммировать
В этой статье в основном представлены несколько инструментов управления пакетами, зависящих от go.Во-первых, в ней рассказывается об установке среды go и настраиваются соответствующие переменные среды, во-вторых, рассказывается о двух типах управления пакетами: управлении внутренними зависимостями и внешними зависимостями. Управление внутренними пакетами зависимостей очень простое.В управлении нативными внешними пакетами зависимостей много дефектов.Затем вводятся godep и govendor, запущенные сообществом open source, и улучшаются функции на основе вендора. Существуют также часто используемые инструменты управления зависимостями пакетов glide и официальный dep, которые будут представлены в следующих статьях, поэтому, пожалуйста, с нетерпением ждите их.