Может кто-нибудь объяснить, почему GOPATH удобен и как его следует использовать в целом?

Я новичок в языке программирования Go, и каждый урок начинается с установки GOPATH в текущую папку проекта.

Я что-то пропустил? Действительно ли программист должен устанавливать GOPATH вручную, когда он cd в его новую папку проекта Go? Я прочитал несколько часто задаваемых вопросов о GOPATH, но все еще не мог обернуть мою голову вокруг этого.

И почему GOROOT существует тогда? Какова его цель?

Существуют ли какие-либо автоматические инструменты, которые определяют, является ли текущий каталог корневой папкой проекта Go (например, по некоторому скрытому файлу), и автоматически изменяют GOPATH на этот каталог?

Спасибо, любые советы действительно ценятся

пс. Например, я разрабатываю совершенно непересекающиеся проекты Go A, B и C, должны ли они жить в единой "рабочей среде"? Наверное, нет, но что мне тогда делать с GOPATH и GOROOT?

Источник

3 ответа

Решение

Цель GOPATH заключается в централизации всех пакетов в одном общем рабочем пространстве. Само по себе это не новая концепция (например, подумайте о Java Classpath), но использование Go значительно проще, поскольку не поддерживается поддержка версий пакетов.

Программист Go не должен устанавливать GOPATH вручную при входе в новую папку проекта. Каждая папка проекта должна быть пакетом сама по себе и находиться в GOPATH наряду с другими пакетами, так GOPATH должен быть установлен только один раз. Учебники начинаются с установки GOPATH для того, чтобы изолировать рабочую область учебника от чего-либо еще (или просто предполагая, что пользователь не установил GOPATH, еще).

GOROOT настроен на предоставление стандартных пакетов программисту Go, вам не нужно ничего делать с ним. Короче говоря, есть одно правило для GOROOTНикогда, никогда не трогай это. Не устанавливайте в нем ничего, не изменяйте стандартные пакеты и т. Д.

Я не знаю инструмента для обнаружения проектов Go в текущем каталоге, но его создание не должно быть очень сложным.

Как вы справляетесь с различными проектами, зависит от вас. Путь Go состоит в том, чтобы поместить каждый проект как пакет в $GOPATH/src каталог и делать все оттуда. Поскольку мне это не очень нравится, я определил GOPATH быть $HOME/.go, Затем я помещаю каждый проект в отдельный каталог где-то еще (где-нибудь на моем компьютере) и вставляю символическую ссылку в каталог проекта в свой $GOPATH/src реж. Затем я могу использовать каждую команду Go toolchain (например, go build myproject), используйте проект как пакет для другого и т. д.

Источник

Вам не нужно устанавливать GOPATH или GOROOT. GOPATH по умолчанию находится в вашем каталоге user/home.

Если GOPATH не задан, предполагается, что он равен $HOME/go в системах Unix и%USERPROFILE%\go в Windows. Если вы хотите использовать пользовательское местоположение в качестве своего рабочего пространства, вы можете установить переменную среды GOPATH.

Go Модули

Кроме этого, теперь есть поддержка Go Modules (начиная с Go 1.11), поэтому вам больше не нужно использовать GOPATH. Тем не менее, это все еще экспериментальная особенность.

Например, вы можете перейти в любой каталог в вашей системе (кроме $GOPATH), и вы можете инициализировать новый модуль Go там, и вы можете работать там. GOPATH не требуется.

Вам просто нужно сделать это один раз (находясь в каталоге):

go mod init

$ GOPATH: Go хранит эти файлы под ним:

  • Исходные файлы ($GOPATH/src)
  • Файлы скомпилированных пакетов ($GOPATH/pkg)
  • Запускаемые файлы ($ GOPATH / bin)

$ GOROOT: где находится исходный код Go, как в стандартной библиотеке Go.

Также запустить любой go install Вы можете добавить исполняемый файл из любой точки вашей системы. $GOPATH/bin к вашей переменной окружения пути, как это:

export PATH=$PATH:$(go env GOPATH)/bin

Больше информации, проверьте это.

Источник

GOPATH позволяет вам собирать исходный код зависимости и полученные скомпилированные двоичные файлы в одном месте. Это кажется очень привлекательной идеей. Тем не менее, я обнаружил, что работаю над несколькими совершенно не связанными проектами Go, и альтернативный подход подошел мне лучше.

Эта стратегия похожа, но отличается от стратегии Элвинара. Я запускаю новый проект в пустой папке и создаю src, И я помещаю в папку этот скрипт под названием env.sh:

if [ `type -p go` = "" ]; then
    export PATH=$PATH:/usr/local/go/bin
fi
export GOPATH=$PWD
export PATH=$PATH:$PWD/bin

Каждый раз, когда я начинаю работать, я использую

. env.sh

Обратите внимание на точку и пробел - они имеют значение.

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

И еще: если ваши зависимости используют переменные среды для тестирования и т. Д., Вы можете поместить их в env.sh тоже. Например, у Горпа есть

export GORP_TEST_DSN=test/testuser/TestPasswd9
export GO_TEST_DSN=testuser:TestPasswd9@/test
Источник
Другие вопросы по тегам