Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-03-10

1 Так повелось, что разработчики, ещё только начинающие знакомиться с Go, часто сталкиваются с проблемойвыбора рабочей директориидля Go-проектов. Новые гоферы часто пугают друг друга словами GOPATH и GOROOT.

2 Однако, в руководствах по быстрому старту с текущей версией Go (1.13) упоминания эти двух "страшных" слов вообще нет.

3 Давайте посмотрим, почему так. Для чистоты эксперимента я развернула свежую Ubuntu на виртуальной машине и установила Go по<a>инструкции из Wiki</a>:

4 sudo add-apt-repository ppa:longsleep/golang-backports sudo apt-get update sudo apt-get install golang-goGo 1.13 установлен и готов к использованию:

5 $ go version go version go1.13 linux/amd64 $ which go /usr/bin/go $ whereis go go: /usr/bin/go /usr/lib/go /usr/share/go /usr/share/man/man1/go.1.gz<h2>GOROOT</h2>

6 Про GOROOT уже было прекрасно написано в<a>статье 2015 года</a>, и эта информация до сих пор актуальна.

7 Забавно, что среди списка директорий, выданных последней командой (whereis go), GOROOT на самом деле нет:

8 $ go env GOROOT /usr/lib/go-1.13Итак, например, если для IDE мне понадобится указать путь к файлам стандартной библиотеки Go, я укажу /usr/lib/go-1.13. Пожалуй, на этом сценарии использования GOROOT в повседневной жизни заканчиваются.

9 <h2>GOPATH и модули</h2>

10 Казалось бы, в этом месте надо бежать устанавливать GOPATH, но я не буду этого делать. На самом деле GOPATH уже и так задан:

11 $ go env GOPATH /home/elena/goМеня устраивает вариант с GOPATH в ~/go, а значит, менять его я не буду.

12 Я сразу создам директорию для своего первого проекта на Go. Это можно сделать в любом месте, например, прямо в домашнем каталоге. Также я сразу начну работать с инструментом<a>Go Modules</a>:

13 $ mkdir ~/hello $ go mod init github.com/rumyantseva/hello go: creating new go.mod: module github.com/rumyantseva/helloДля команды go mod init я указала уникальный путь модуля моего проекта. По этому пути прокси или другой инструмент в случае необходимости смогут найти файлы моего проекта.

14 После вызова команды go mod init в моём домашнем каталоге появилась директория go:

15 $ tree ~/go /home/elena/go └── pkg └── mod └── cache └── lock 3 directories, 1 fileПри этом lock-файл (в самом низу дерева) пока пуст. В каталоге ~/hello появился файл go.mod со следующим содержанием:

16 module github.com/rumyantseva/hello go 1.13Именно в go.mod впоследствии будет храниться вся информация о зависимостях моего модуля.

17 Давайте теперь напишем приложение, использующее внешнюю зависимость. В директории ~/hello я создаю файл main.go и пишу в него такой код:

18 package main import ( "github.com/sirupsen/logrus" ) func main() { logrus.Info("Hello, world!") }Конечно, в реальной жизни для написания "Hello, world!" можно обойтись и без<a>logrus</a>, но в этом примере эта библиотека поможет нам узнать, где хранятся файлы внешних зависимостей.

19 Запускаю приложение самым простым способом:

20 $ go run main.go go: finding github.com/sirupsen/logrus v1.4.2 go: downloading github.com/sirupsen/logrus v1.4.2 go: extracting github.com/sirupsen/logrus v1.4.2 go: downloading golang.org/x/sys v0.0.0-20190422165155-953cdadca894 go: extracting golang.org/x/sys v0.0.0-20190422165155-953cdadca894 go: finding golang.org/x/sys v0.0.0-20190422165155-953cdadca894 INFO[0000] Hello, world!Перед тем, как приложение было собрано и запущено, сработал инструмент go mod. Он определил мою внешнюю зависимость github.com/sirupsen/logrus, взял её последнюю на данный момент версию v1.4.2 и отправился за транзитивными зависимостями.

21 В файл go.mod добавилась строка с описанием зависимости от logrus:

22 module github.com/rumyantseva/hello go 1.13 require github.com/sirupsen/logrus v1.4.2 // indirectТакже появился файл go.sum, в котором, помимо хэша зависимости logrus, хранится информация о хэшах транзитивных зависимостей:

23 github.com/davecgh/go-spew v1.1.1/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38= github.com/konsorten/go-windows-terminal-sequences v1.0.1/go.mod h1:T0+1ngSBFLxvqU3pZ+m/2kptfBszLMUkC4ZK/EgS/cQ= github.com/pmezard/go-difflib v1.0.0/go.mod h1:iKH77koFhYxTK1pcRnkKkqfTogsbg7gZNVY4sRDYZ/4= github.com/sirupsen/logrus v1.4.2 h1:SPIRibHv4MatM3XXNO2BJeFLZwZ2LvZgfQ5+UNI2im4= github.com/sirupsen/logrus v1.4.2/go.mod h1:tLMulIdttU9McNUspp0xgXVQah82FyeX6MwdIuYE2rE= github.com/stretchr/objx v0.1.1/go.mod h1:HFkY916IF+rwdDfMAkV7OtwuqBVzrE8GR6GFx+wExME= github.com/stretchr/testify v1.2.2/go.mod h1:a8OnRcib4nhh0OaRAV+Yts87kKdq0PP7pXfy6kDkUVs= golang.org/x/sys v0.0.0-20190422165155-953cdadca894 h1:Cz4ceDQGXuKRnVBDTS23GTn/pU5OE2C0WrNTOYK1Uuc= golang.org/x/sys v0.0.0-20190422165155-953cdadca894/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=Где же сам код зависимостей? Его можно найти в ~/go/pkg/mod. Также, в ~/go/pkg будут храниться контрольные суммы и другая служебная информация для работы с зависимостями.

24 Если вы уже сталкивались с инструментомgo get, знаете, что он при вытягивании зависимостей фактически клонирует репозитории (например, в случае git с помощью git clone). Но go mod работает не так. Для go mod основная единица кода - модуль.

25 Модули представляют собой архивы. Во время работы с зависимостями go mod явно (если вы вызывали команду go mod download) или неявно (если вы запустили компиляцию приложения) скачивает и распаковывает архивы через GOPROXY. Давайте посмотрим, как прокси задан в Go 1.13 по умолчанию:

26 $ go env GOPROXY https://proxy.golang.org,directИтак, в качестве прокси при сборке моего "Hello, World!" использовался<a>proxy.golang.org</a>. Конечно, эту переменную можно изменить, выбрав другое хранилище модулей. Например, можно развернуть свой собственный внутренний прокси компании, где будут храниться, в том числе, внутренние библиотеки, код которых не публиковался в open source.

27 В общем, если я начинаю новый проект и не против использования Go Modules, мне можно ничего не знать о GOPATH. Go самостоятельно создаст директорию ~/go тогда, когда это будет нужно.

28 <h2>Когда нужен GOPATH?</h2>

29 Если вы принципиально не используете Go Modules (например, в легаси-проекте), уйти от более явной работы с GOPATH может быть не так просто.

30 Чтобы посмотреть, что будет с моим проектом, если я решила не использовать go mod, удаляю файлы ~/hello/go.mod и ~/hello/go.sum. Также я удалю и ~/go, чтобы вернуться к тому состоянию системы, которое у меня было в самом начале:

31 rm -rf ~/go ~/hello/go.mod ~/hello/go.sumВ директории ~/hello остаётся только файл main.go. Что теперь произойдет, если я попробую запустить его с помощью go run?

32 $ go run main.go main.go:4:2: cannot find package "github.com/sirupsen/logrus" in any of: /usr/lib/go-1.13/src/github.com/sirupsen/logrus (from $GOROOT) /home/elena/go/src/github.com/sirupsen/logrus (from $GOPATH)Вот они, эти страшные GOROOT и GOPATH!

33 Чтобы скомпилировать приложение, мне надо подтянуть зависимость в GOPATH. Делаю это с помощью старого доброго go get:

34 $ go get -v github.com/sirupsen/logrus github.com/sirupsen/logrus (download) created GOPATH=/home/elena/go; see 'go help gopath' get "golang.org/x/sys/unix": found meta tag get.metaImport{Prefix:"golang.org/x/sys", VCS:"git", RepoRoot:"https://go.googlesource.com/sys"} at //golang.org/x/sys/unix?go-get=1 get "golang.org/x/sys/unix": verifying non-authoritative meta tag golang.org/x/sys (download) golang.org/x/sys/unix github.com/sirupsen/logrusЧто произошло? Первым делом, go get создал директорию ~/go (ту, что указана в качестве GOPATH). Затем начался процесс клонирования репозиториев с зависимостями. Забавно, что клонирование репозиториев выглядит заметно медленнее, чем вариант, когда мы использовали go mod для скачивания и распаковки модулей. Тем не менее, код зависимостей теперь можно найти внутри ~/go/src/.

35 Кстати, на моей чистой установке Ubuntu до сих пор не было клиента git и, чтобы go get сработал, пришлось его установить.

36 Запускаю приложение:

37 $ go run main.go INFO[0000] Hello, world!<h4>Работает!</h4>

38 Вот только на уровне приложения я теперь не отслеживаю версии внешних зависимостей. Что, если из-за уязвимости в какой-то момент в репозитории github.com/sirupsen/logrus окажется не ожидаемый мной логгер, а какой-нибудь вредоносный код?

39 Рано или поздно, мне всё-таки понадобится инструмент для работы с зависимостями, и если Go Modules по какой-то причине не подходит, придётся искать что-то другое...

40 <h2>Заключение</h2>

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

42 Если вы начинаете новый проект, попробуйте Go Modules! Возвращаться к старому подходу к работе с зависимостями имеет смысл, только если что-то пошло не так. Кстати, если вы предпочитаете хранить все зависимости внутри проекта, Go Modules поддерживает режим vendor.

43 Если вам нужно работать с уже существующим проектом, и по каким-то причинам его не хочется переводить на Go Modules, в документации к проекту важно указатьособенности его развёртывания и управления зависимостями. Если в проект придут новички, незнакомые со старыми подходами к работе с зависимостями, им будет гораздо проще разобраться с проектом, если вся документация будет на месте.