Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-26

1 В Go используется нестандартная система публикации модулей. В отличие от большинства других популярных языков, в Go не нужно самостоятельно загружать код в централизованные репозитории. Каждый Go-модуль публикуется только в репозиториях исходного кода, например, на GitHub или GitLab.

2 В этом уроке мы рассмотрим, как работает публикация модулей в Go.

3 <h2>Как работает загрузка через прокси-сервер</h2>

4 Команда go не загружает пакеты напрямую из хранилищ исходного кода, а опрашивает<a>прокси-сервер</a>.

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

6 Еще пользователя оберегает<a>база данных контрольных сумм</a>, которая хранит записи из файловgo.sum. Представьте, что вы загружаете модуль командой go. В этот момент команда считывает хэш загружаемого модуля и сверяет его с данными из базы контрольных сумм. Если они не совпадают, то установка завершается с ошибкой.

7 <h2>Как найти запрашиваемый пакет в прокси</h2>

8 Проследим установку пакета на примере популярной библиотеки<a>lo</a>. Возьмем базовый пример:

9 Создадим модуль со структурой:

10 И содержимымhxlt.go

11 Вызов команды go get github.com/samber/lo@latest проверит переменную окружения GOPROXY. Допустим, она содержит список прокси-серверов:

12 Тогда команда go выполнит следующие шаги:

13 <ul><li>Запросит последнюю версию github.com/samber/lo от сервера https://corp.example.com/</li>

14 <li>Запросит последнюю версию github.com/samber от сервера https://corp.example.com/</li>

15 <li>Запросит последнюю версию github.com от сервера https://corp.example.com/</li>

16 </ul>Представим, что все запросы к<a>https://corp.example.com/</a>выдали ошибку 404 или 410. Тогда команда перейдет к следующей записи:

17 <ul><li>Запросит последнюю версию github.com/samber/lo от сервера https://proxy.golang.org/</li>

18 <li>Запросит последнюю версию github.com/samber от сервера https://proxy.golang.org/</li>

19 <li>Запросит последнюю версию github.com от сервера https://proxy.golang.org/</li>

20 </ul>Если в результате найдется один модуль с именем github.com/samber/lo и пакетом lo, то команда go обновит файлыgo.mod и go.sumи скачает сам пакет.

21 <h2>Как найти последнюю версию пакета</h2>

22 Продолжим пример с запросом go get github.com/samber/lo@latest. Здесь можно использовать атрибут @latest, и тогда go определит последнюю версию запрашиваемого пакета.

23 Рассмотрим, как это работает. Допустим в системе контроля версий проекта есть несколько веток и тегов:

24 <ul><li>Ветка main</li>

25 <li>Ветка v2</li>

26 <li>Тег v1.0.0</li>

27 <li>Тег 1101-1663105068</li>

28 </ul>В этом случае последней версией будет считатьсятег v1.0.0, потому что Go отдает приоритет тегам перед ветками. Обратите внимание, что используются только те теги, которые начинаются с буквы v и следуют<a>семантическому версионированию</a>.

29 Если в проекте нет тегов, команда создает<a>псевдо-версию</a>, используя последний коммит.

30 <h2>Как публиковать модуль</h2>

31 Попробуем опубликовать собственный модуль. Этот процесс состоит из нескольких шагов.

32 Создаем go-модуль:

33 Добавляем код в модуль, созданный выше:

34 Запускаем go mod tidy, чтобы загрузить недостающие пакеты и удалить лишние:

35 Дальше нужно отформатировать код с помощью встроенного инструмента go fmt. Не забывайте запускать форматирование перед публикацией пакета - так вы убедитесь, что вывод команды не содержит ошибок.

36 После этого проверяем код линтером. Для Go написано множество линтеров, поэтому появились утилиты-аггрегаторы, запускающие несколько линтеров разом. Мы рекомендуем пользоваться<a>golangci-lint</a>.

37 Остался последний шаг - добавляем новый тег в репозиторий:

38 Модуль готов к скачиванию! Чтобы пользователи смогли найти его до загрузки, можно запустить команду go list - она добавит модуль в<a>индекс go.pkg</a>.

39 <h2>Как добавлять обратно несовместимые изменения</h2>

40 В работе над проектом разработчики могут переименовывать функции, изменять ее сигнатуры, удалять устаревший код. Подобные действия могут вносить ломающие изменения в API. Это значит, что пользователям придется вносить изменения в собственную кодовую базу.

41 Go-разработчики серьезно относятся к подобным изменениям в API. Если вам нужно внести ломающие изменения, не получится ограничиться добавлением тега с увеличенной мажорной версией. Рассмотрим подробнее, как устроено внесение таких изменений.

42 Возьмем модуль из примера выше. Его структура выглядит так:

43 При этом файлgo.modвыглядит так:

44 Чтобы создать версию 2.0.0 этого модуля, нужно обновитьgo.mod, чтобы он содержал в названии новую мажорную версию пакета. Сохраним текущий код в ветке v1:

45 Обновимgo.modфайл, добавив ему в название v2:

46 Если бы в проекте было несколько пакетов, то для папки с v2 пришлось бы обновить все импорты, чтобы они включали суффикс v2. Добавим тег и опубликуем:

47 <h2>Выводы</h2>

48 <ul><li>Чтобы опубликовать Go-модуль, нужно внести его в хранилище исходного кода: то есть добавить сам код, файлыgo.modиgo.sumв систему контроля версий</li>

49 <li>Имя модуля при этом должно содержать путь до модуля в этом хранилище</li>

50 <li>Модули по умолчанию загружаются не из хранилищ кода, а из центрального репозитория пакетов</li>

51 <li>Чтобы точнее указать требования к версии пакета, можно использовать<a>version query</a>. Отсутствующий version query имеет дефолтное значение latest</li>

52 <li>Перед публикацией не забывайте форматировать код и проверять его линтером</li>

53 <li>В работе над публичными проектами на Go добавляйте новые версии, а не изменяйте уже существующие</li>

54 </ul>