Всё что вы хотели знать про GOPATH и GOROOT
Несмотря на то, что Go считается одним из самых легких для входа языков, приходится регулярно слышать — «как-то все непонятно, какие-то переменные GOROOT и GOPATH нужно устанавливать». Хотя тема полностью раскрыта на официальном сайте Go, но будет не лишним объяснить совсем простым языком.TL; DR
Теперь чуть подробнее:
GOROOTGOROOT это переменная, указывающая, где лежит, собственно вся бинарная сборка Go и исходные коды. Что-то вроде JAVA_HOME. Устанавливать эту переменную ручками нужно только в тех случаях, если вы ставите Go под Windows не с помощью MSI-инсталлера, а из zip-архива. Ну, или если вы хотите держать несколько версий Go, каждая в своей директории.Раньше (до Go 1.0) эта переменная была нужна — её использовали скрипты сборки, равно как и GOARCH и GOOS. Но после Go 1.0 немного изменилась внутренняя логика работы go tool и сейчас значение GOROOT хардкодится на этапе сборки или инсталляции. Тоесть, go — дефолтно проинсталлированный — знает это значение и так. Его можно посмотреть с помощью команды:
go env GOROOT В MacOS X это /usr/local/go/, в Linux тоже (хотя может зависеть от дистрибутива), в Windows — С:\Go.GOPATH А вот переменная GOPATH очень важна и нужна и её нужно установить обязательно, впрочем только один раз. Это ваш workspace, где будет лежать код и бинарные файлы всего с чем вы будете в Go работать. Поэтому выбирайте удобный вам путь и сохраняйте его в GOPATH. К примеру: export GOPATH=~/go export GOPATH=~/gocode export GOPATH=~/Devel/go export GOPATH=~/Projects/go Ну и обязательно это сохраните в .profile или как вы там сохраняете переменные: echo «export GOPATH=~/go» >> ~/.profile (или .bash_profile) Всё, сделайте это один раз и забудьте. Создайте только эту директорию, если её еще и нет, и на этом готово. Теперь любой вызов go get github.com/someuser/somelib автоматически будет скачивать исходники в $GOPATH/src, а бинарный результат компиляции складывать в $GOPATH/pkg или $GOPATH/bin (для библиотек и исполняемых файлов соответственно).PATH Это опционально, но желательно сразу тоже сделать, раз уж вы взялись за настройку среды. Рано или поздно вы захотите пользоваться какими-то Go-программами, которые будут лежать в вашей GOPATH/bin. Чтобы их без лишних телодвижений использовать, добавьте к PATH директорию $GOPATH/bin: export PATH=$PATH:$GOPATH/bin Команда go install собирает и инсталлирует бинарник именно в эту директорию, поэтому это исключительно для удобства.Структура Workspace Теперь давайте посмотрим внимательно на структуру директории GOPATH. Возьму пример из официальной документации: bin/ hello # программа hello pkg/ linux_amd64/ # каталог этого уровня определяет ось и архитектуру для бинарных файлов github.com/user/ stringutil.a # объектный бинарный файл пакета stringutil src/ github.com/user/ hello/ hello.go # исходный код программы hello stringutil/ reverse.go # исходный код библиотеки stringutil Достаточно просто, не так ли? Важно понимать, что никто не обязывает называть директории в src/ по какому-то формату. Можно использовать и src/test/my_first_app/main.go и src/anyname/main.go —, но если вы работаете с системами контроля версий (а вы таки работаете)), то вам это бесспорно станет удобно — утилиты go get/install используют это соглашения наименования, чтобы сделать работу с системами контроля версий безбожно простой.Дополнительно Переменная GOPATH аналогична стандартной PATH — можно указывать несколько директорий, через ':'. GOPATH=~/go:~/other_workspace. Это в очень редких случаях бывает полезно (например, для работы с внешними менеджерами зависимостей вроде gpm), но в 99% это не нужно, и просто так рекомендуется использовать только одну директорию в GOPATH.В конце-концов, если вам нужны раздельные workspace-ы, всегда можно заменить переменную GOPATH на нужную (в скрипте сборки, к примеру). Так, собственно, и делают.Ссылки golang.org/doc/installgolang.org/doc/code.htmldave.cheney.net/2013/06/14/you-dont-need-to-set-goroot-really