Так повелось, что разработчики, еще только начинающие знакомиться с Go, часто сталкиваются с проблемой выбора рабочей директории для Go-проектов. Вот и в чате конференции GolangConf тоже задавался этот вопрос. Новые гоферы часто пугают друг друга словами GOPATH и GOROOT. Однако, в руководствах по быстрому старту с текущей версией Go (1.13) упоминания эти двух «страшных» слов вообще нет. Давайте посмотрим, почему так. Для чистоты эксперимента я развернула свежую Ubuntu на виртуальной машине и установила Go по инструкции из Wiki: Go 1.13 установлен и готов к использованию: Про GOROOT уже было прекрасно написано в статье 2015-года, и эта информация до сих пор актуальна. Забавно, что среди списка директорий, выданных последней командой (whereis go), GOROOT на самом деле нет: Итак, например, если для IDE мне понадобится указать путь к файлам стандартной библиотеки Go, я укажу /usr/lib/go-1.13. Пожалуй, на этом сценарии использования GOROOT в повседневной жизни заканчиваются. Казалось бы, в этом месте надо кинуться устанавливать GOPATH, но я не буду этого делать. На самом деле GOPATH уже и так задан: Меня устраивает вариант с GOPATH в ~/go, а значит, менять его я не буду. Я сразу создам директорию для своего первого проекта на Go. Это можно сделать в любом месте, например, прямо в домашнем каталоге. Также я сразу начну работать с инструментом Go Modules:  Для команды go mod init я указала уникальный путь модуля моего проекта. По этому пути прокси или другой инструмент в случае необходимости сможет найти файлы моего проекта. После вызова команды go mod init в моем домашнем каталоге появилась директория go: При этом lock-файл (в самом низу дерева), пока пуст. В каталоге ~/hello появился файл go.mod со следующим содержанием: Именно в go.mod впоследствии будет храниться вся информация о зависимостях моего модуля. Давайте теперь напишем приложение, использующее внешнюю зависимость. В директории ~/hello я создаю файл main.go и пишу в него такой код: Конечно, в реальной жизни для написания "Hello, world!" можно обойтись и без logrus, но в этом примере эта библиотека поможет нам узнать, где хранятся файлы внешних зависимостей. Запускаю приложение самым простым способом: Перед тем, как приложение было собрано и запущено, сработал инструмент go mod. Он определил мою внешнюю зависимость github.com/sirupsen/logrus, взял ее последнюю на данный момент версию v1.4.2 и отправился за транзитивными зависимостями.  В файл go.mod добавилась строка с описанием зависимости от logrus: Также появился файл go.sum, в котором помимо хэша зависимости logrus хранится информация о хэшах транзитивных зависимостей: Где же сам код зависимостей? Его можно найти в ~/go/pkg/mod. Также, в ~/go/pkg будут храниться контрольные суммы и другая служебная информация для работы с зависимостями. Если вы уже сталкивались с инструментом go get, знаете, что он при вытягивании зависимостей фактически клонирует репозитории (например, в случае git с помощью git clone). Но go mod работает не так. Для go mod основная единица кода — модуль. Модули представляют собой архивы. Во время работы с зависимостями go mod явно (если вы вызывали команду go mod download) или неявно (если вы запустили компиляцию приложения) скачивает и распаковывает архивы через GOPROXY. Давайте посмотрим, как прокси задан в Go 1.13 по умолчанию: Итак, в качестве прокси при сборке моего "Hello, World!" использовался proxy.golang.org. Конечно, эту переменную можно изменить, выбрав другое хранилище модулей. Например, можно развернуть свой собственный внутренний прокси компании, где будут храниться, в том числе, внутренние библиотеки, код которых не публиковался в open source. В общем, если я начинаю новый проект и не против использования Go Modules, мне можно ничего не знать о GOPATH. Go самостоятельно создаст директорию ~/go тогда, когда это будет нужно.  Если вы принципиально не используете Go Modules (например, в легаси-проекте), уйти от более явной работы с GOPATH может быть не так просто. Чтобы посмотреть, что будет с моим проектом, если я решила не использовать go mod, удаляю файлы ~/hello/go.mod и ~/hello/go.sum. Также я удалю и ~/go, чтобы вернуться к тому состоянию системы, которое у меня было в самом начале: В директории ~/hello остается только файл main.go. Что теперь произойдет, если я попробую запустить его с помощью go run? Вот они, эти страшные GOROOT и GOPATH :) Для того, чтобы скомпилировать приложение, мне надо подянуть зависимость в GOPATH. Делаю это с помощью старого доброго go get: Что произошло? Первым делом, go get создал директорию ~/go (ту, что указана в качестве GOPATH). Затем начался процесс клонирования репозиториев с зависимостями. Забавно, что клонирование репозиториев выглядит заметно медленнее, чем вариант, когда мы использовали go mod для скачивания и распаковки модулей. Тем не менее, код зависимостей теперь можно найти внутри ~/go/src/.  Кстати, на моей чистой установке Ubuntu до сих пор не было клиента git и, для того чтобы go get сработал, пришлось его установить. Запускаю приложение: Работает! Вот только на уровне приложения я теперь не отслеживаю версии внешних зависимостей. Что если из-за уязвимости в какой-то момент в репозитории github.com/sirupsen/logrus окажется не ожидаемый мной логгер, а какой-нибудь вредоносный код? Рано или поздно, мне всё-таки понадобится инструмент для работы с зависимостями, и если Go Modules по какой-то причине не подходит, придётся искать что-то другое... В этой статье не рассмотрены некоторые специфичные моменты, и работа с внешними зависимостями в Go по-прежнему может вызвать много вопросов. Тем не менее, новые версии Go хотя бы не накладыают ограничений на то, где могут быть созданы рабочие каталоги ваших проектов. Если вы начинаете новый проект, попробуйте Go Modules! Возвращаться к старому подходу к работе с зависимостями имеет смысл, только если что-то пошло не так. Кстати, если вы предпочитаете хранить все зависимости внутри проекта, Go Modules поддерживает режим vendor. Если вам нужно работать с уже существующим проектом, и по каким-то причинам его не хочется переводить на Go Modules, в документации к проекту важно указать особенности его развертывания и управления зависимостями. Если в проект придут новички незнакомые со старыми подходами к работе с зависимостями, им будет гораздо проще разобраться с проектом, если вся документация будет на месте. Кстати, 7-го октября на конференции GolangConf в качестве одной из специальных активностей, мы планируем экспертную зону, где любой желающий сможет задать любые вопросы по Go членам программного комитета конференции и энтузиастам российского Go-сообщества. Установить Go? Разобраться с зависимостями? Написать микросервис? Это к нам! ПК конференции GolangConf