Окончательный учебник по модулям Go

Go

Поиск в WeChat【Жареная рыба с мозгами] Обратите внимание на эту жареную рыбу с печенью.
эта статьяGitHub GitHub.com/Vicious Genetics/Нет...Входит в мою серию статей, материалов и книг по Go с открытым исходным кодом.

Модули Go – это официально анонсированное решение для зависимостей проекта на языке Go. Модули Go (ранее vgo) были официально выпущены в версии Go1.11, готовы в версии Go1.14 и могут использоваться в производстве (готовы к работе), официальные лица Go также поощрять всех пользователей переходить на модули Go с других инструментов управления зависимостями.

И Go1.14, который наконец-то официально вышел в ближайшее время, официальное лицо Go лично «призывает» вас использовать:

image

Поэтому в сегодняшней статье я представлю вам «окончательное введение» в модули Go, и вы можете обсудить их вместе.

Модули Go — это инструмент управления зависимостями проектов, официально объявленный на языке Go. Модули Go (ранее vgo) были официально выпущены в версии Go1.11, готовы к версии Go1.14 и могут использоваться в производстве (готовы к работе), все пользователи рекомендуется перейти на модули Go из других инструментов управления зависимостями.

Что такое Go-модули

Модули Go — это зависимое решение для языка Go, выпущенное в версии Go1.11, улучшенное в версии Go1.12, расширенное в версии Go1.13 и официально рекомендованное для использования в рабочей среде в версии Go1.14.

Модули Go в настоящее время интегрированы в цепочку инструментов Go.Пока Go установлен, модули Go можно использовать естественным образом, и появление модулей Go также разрешило несколько распространенных споров до выхода Go1.11:

  1. Go имеет давнюю проблему управления зависимостями.
  2. «Отменить» существующие шаблоны использования GOPATH.
  3. Другие инструменты управления зависимостями в сообществе унификации (предоставляющие возможности миграции).

Эти кусочки GOPATH

Мы упоминали, что одной из задач, решаемых модулями Go, является «устранение» GOPATH, но что такое GOPATH и какой рекомендуемый режим GOPATH?

что такое ГОПАТ

Давайте сначала посмотрим на первый вопрос, что такое GOPATH, мы можем ввести следующую команду для проверки:

$ go env
GOPATH="/Users/eddycjy/go"
...

мы входимgo envПосле командной строки вы можете просмотреть результат переменной GOPATH, Мы входим в каталог, чтобы просмотреть его, следующим образом:

go
├── bin
├── pkg
└── src
    ├── github.com
    ├── golang.org
    ├── google.golang.org
    ├── gopkg.in
    ....

В каталоге GOPATH есть три подкаталога:

  • bin: Хранит скомпилированные двоичные файлы.
  • pkg: сохраняет предварительно скомпилированные объектные файлы для ускорения последующей компиляции программы.
  • источник: хранить все.goдокументации или исходного кода. При написании приложений, пакетов и библиотек Go обычно начинают с$GOPATH/src/github.com/foo/barпуть для хранения.

Поэтому при использовании режима GOPATH нам нужно хранить код приложения в фиксированном$GOPATH/srcкаталог, и если вы выполнитеgo getдля извлечения внешних зависимостей будут автоматически загружены и установлены на$GOPATHПод содержанием.

Почему шаблон GOPATH устарел

в GOPATH$GOPATH/srcдействовать под.goХранение файлов или исходного кода, мы можем назвать это режимом GOPATH, в этом режиме, похоже, нет проблем, поэтому почему мы хотим его устареть, см. следующие причины:

  • В режиме GOPATH отсутствует концепция контроля версий, которая фатально ошибочна и вызывает как минимум следующие проблемы:
    • в исполненииgo getКогда вы не можете передать какую-либо ожидаемую информацию о версии, то есть вы не можете знать, какую версию вы в настоящее время обновляете, и вы не можете получить конкретную версию, которую вы ожидаете, указав.
    • При запуске приложения Go вы не можете гарантировать, что у других будет такая же версия сторонних библиотек, от которых вы ожидаете зависеть, то есть при управлении зависимостями проекта вы не можете гарантировать, что у всех будет одинаковая версия зависимостей. .
    • Вы не можете справиться с проблемой ссылок разных версий v1, v2, v3 и т. д., потому что пути импорта в режиме GOPATH одинаковы, всеgithub.com/foo/bar.
  • Язык Go официально начал продвигать модули Go (предшественник vgo) начиная с Go1.11.Начиная с Go1.13 режим использования GOPATH больше не рекомендуется, и модули Go постепенно становятся стабильными, поэтому нет необходимости продолжать использовать Режим GOPATH для новых проектов.

Продукт в режиме GOPATH

Go1 был выпущен 28 марта 2012 г., а Go1.11 был официально выпущен 25 августа 2018 г. (источник данных: тег Github).В течение этого промежутка не было модулей Go.В первые дни можно сказать, что потому что он был только что выпущен, и немногие люди использовали его, поэтому он не был явно разоблачен, но на более позднем этапе все больше и больше людей использовали язык Go, так что мне делать?

В это время в сообществе постепенно появилось большое количество решений для зависимостей, и их трудно выбрать, включая известную модель каталогов поставщиков и инструмент управления зависимостями dep, который когда-то считался «официальным объявлением». .

Но почему dep не становится официальным объявлением, так это потому, что по мере того, как Расс Кокс и другие члены команды Go продолжают подробно обсуждать, выясняется, что некоторые детали dep кажутся все менее и менее подходящими для Go, поэтому официальный представитель принял другое предложение.Результатом плана было выпустить vgo (предшественник модулей Go, вы можете это знать, не нужно глубоко разбираться в этом) в начале, и, наконец, превратились в модули Go, которые мы видели сейчас, которые также официально представлен Go1.11.Toolchain for Go.

Так что это не столько «продукт режима GOPATH», сколько история дает важные уроки для настоящего, отсюда и появление модулей Go.

Основное использование модулей Go

После предварительного понимания прошлого и настоящего Go-модулей мы официально вступили в использование Go-модулей.Сначала создадим проект Go-модулей с нуля (в принципе, созданный каталог не должен помещаться в GOPATH).

предоставленная команда

В модулях Go мы можем сделать это с помощью следующих команд:

Заказ эффект
go mod init Сгенерировать файл go.mod
go mod download Загрузите все зависимости, указанные в файле go.mod.
go mod tidy Приведите в порядок существующие зависимости
go mod graph Просмотр существующей структуры зависимостей
go mod edit Отредактируйте файл go.mod
go mod vendor Экспорт всех зависимостей проекта в каталог поставщика
go mod verify Проверьте, не был ли изменен модуль
go mod why Узнайте, почему вам нужно зависеть от модуля

предоставленные переменные среды

В модулях Go есть следующие общие переменные среды, которые мы можем передатьgo envкоманду для просмотра следующим образом:

$ go env
GO111MODULE="auto"
GOPROXY="https://proxy.golang.org,direct"
GONOPROXY=""
GOSUMDB="sum.golang.org"
GONOSUMDB=""
GOPRIVATE=""
...

GO111MODULE

Язык Go предоставляет переменную среды GO111MODULE в качестве переключателя для модулей Go, что позволяет устанавливать следующие параметры:

  • auto: включает модули Go, если проект содержит файл go.mod, который в настоящее время по-прежнему используется по умолчанию в версиях с Go1.11 по Go1.14.
  • on: Включить модули Go, рекомендуемая настройка, будет использоваться по умолчанию в будущих выпусках.
  • off: отключить модули Go, этот параметр не рекомендуется.
Немного истории GO111MODULE

Вы могли заметить, что название GO111MODULE довольно «своеобразное», на самом деле в языке Go часто встречаются такие поэтапные переменные Имя GO111MODULE представляет собой переменные, добавленные языком Go в версии 1.11 для модуля.

Например, в версии Go1.5 также была выпущена системная переменная окружения GO15VENDOREXPERIMENT, которая использовалась для включения поддержки каталога vendor.На тот момент ее значение по умолчанию не было включено, а только как экспериментальное. Впоследствии он изменил значение по умолчанию на on в версии Go1.6 и, наконец, стал официальным, а системная переменная GO15VENDOREXPERIMENT вышла из стадии истории.

В будущем переменная системной среды GO111MODULE также столкнется с этой проблемой, и она сначала будет скорректирована до значения по умолчанию on (я думал изменить его на on в Go1.13, и PR был объединен, но в итоге изменил вернуться к авто по разным причинам), а затем удалить поддержку GO111MODULE, мы предполагаем, что GO111MODULE следует удалить в Go2, потому что, если поддержка GO111MODULE будет удалена напрямую, будут проблемы с совместимостью.

GOPROXY

Эта переменная среды в основном используется для установки прокси модуля Go (прокси модуля Go).

Значение GOPROXY по умолчанию:https://proxy.golang.org,direct, это очень серьезная проблема, т.proxy.golang.orgОн недоступен в Китае, поэтому это напрямую заблокирует ваш первый шаг, поэтому вы должны установить внутренний прокси-сервер модуля Go одновременно с открытием модулей Go и выполнить следующую команду:

$ go env -w GOPROXY=https://goproxy.cn,direct

Значение GOPROXY представляет собой список прокси-модулей Go, разделенных запятыми, что позволяет установить несколько прокси-модулей. последующие операции Любой прокси модуля Go.

что прямо

В только что установленном значении мы можем обнаружить, что в списке значений есть «прямой» флаг, что он делает?

На самом деле «прямой» — это специальный индикатор, используемый для указания вернуться к исходному адресу версии модуля для извлечения (например, GitHub и т. д.), сценарий следующий: когда предыдущий прокси-модуль Go в списке значений возвращает ошибка 404 или 410, Go автоматически пробует следующий в списке, возвращается к источнику при встрече с «прямым», то есть возвращается к исходному адресу для выборки, и завершает работу при обнаружении EOF и выдает ошибку типа «недопустимая версия». : неизвестная версия...".

GOSUMDB

Его значение представляет собой базу данных контрольных сумм Go, которая используется для гарантии того, что данные версии извлеченного модуля не были подделаны при извлечении версии модуля (независимо от того, были ли они извлечены с исходного сайта или через прокси модуля Go). может быть фальсификация, и она будет немедленно прекращена.

Значения по умолчанию для GOSUMDB:sum.golang.org, также недоступен в Китае, но GOSUMDB может быть проксирован прокси модуля Go (см.: Проксирование базы данных контрольной суммы).

Поэтому мы можем решить это, установив GOPROXY и прокси модуля, который мы установили ранее.goproxy.cnМожет поддерживать агентsum.golang.org, так что вам не нужно слишком беспокоиться об этой проблеме после настройки GOPROXY.

Кроме того, если у вас есть пользовательские требования к значению GOSUMDB, он поддерживает следующие форматы:

  • Формат 1:<SUMDB_NAME>+<PUBLIC_KEY>.
  • Формат 2:<SUMDB_NAME>+<PUBLIC_KEY> <SUMDB_URL>.

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

GONOPROXY/GONOSUMDB/GOPRIVATE

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

Чтобы быть более конкретным, это сценарий, когда используются модули, к которым не может получить доступ ни прокси модуля Go, указанный GOPROXY, ни база данных контрольных сумм Go, указанная GOSUMDB.

Обычно рекомендуется устанавливать GOPRIVATE напрямую, и его значение будет использоваться как значение по умолчанию для GONOPROXY и GONOSUMDB, поэтому рекомендуется использовать GOPRIVATE напрямую.

А их значения - это все префикс пути модуля, разделенный английской запятой ",", то есть может быть задано более одного, например:

$ go env -w GOPRIVATE="git.example.com,github.com/eddycjy/mquote"

После установки модули с префиксом git.xxx.com и github.com/eddycjy/mquote считаются частными модулями.

Если мы не хотим сбрасывать каждый раз, мы также можем использовать подстановочные знаки, например:

$ go env -w GOPRIVATE="*.example.com"

Таким образом, все поддомены, путь к модулю которых — example.com (например: git.example.com), не будут проходить через прокси модуля Go и базу данных контрольных сумм Go.Следует отметить, что сам example.com не включен.

Включить модули Go

В настоящее время модули Go не включены по умолчанию, поэтому язык Go предоставляет переменную среды GO111MODULE в качестве переключателя для модулей Go, что позволяет устанавливать следующие параметры:

  • auto: включает модули Go, если проект содержит файл go.mod, который в настоящее время по-прежнему используется по умолчанию в версиях с Go1.11 по Go1.14.
  • on: Включить модули Go, рекомендуемая настройка, будет использоваться по умолчанию в будущих выпусках.
  • off: отключить модули Go, этот параметр не рекомендуется.

Если вы не уверены, каково ваше текущее значение, вы можете сделатьgo envкоманда, чтобы увидеть результат:

$ go env
GO111MODULE="off"
...

Если вам нужно изменить значение GO111MODULE, рекомендуется передатьgo envкоманда для установки:

 $ go env -w GO111MODULE=on

Однако следует отметить, что если соответствующая переменная системной среды имеет значение (задает его), появится следующее предупреждающее сообщение:warning: go env -w GO111MODULE=... does not override conflicting OS environment variable.

Или вы можете добиться этого, установив переменные системной среды напрямую (вы также можете написать соответствующий файл .bash_profile):

$ export GO111MODULE=on

Инициализировать проект

После завершения открытия модулей Go нам нужно создать пример проекта для демонстрации, выполнив следующую команду:

$ mkdir -p $HOME/eddycjy/module-repo 
$ cd $HOME/eddycjy/module-repo

Затем инициализируйте модули Go следующим образом:

$ go mod init github.com/eddycjy/module-repo
go: creating new go.mod: module github.com/eddycjy/module-repo

в исполненииgo mod initмы указали путь импорта модуля какgithub.com/eddycjy/module-repo. Затем мы создаем файл main.go в корневом каталоге проекта следующим образом:

package main

import (
    "fmt"
    "github.com/eddycjy/mquote"
)

func main() {
	fmt.Println(mquote.GetHello())
}

Затем выполните в корневом каталоге проектаgo get github.com/eddycjy/mquoteкоманда, как показано ниже:

$ go get github.com/eddycjy/mquote 
go: finding github.com/eddycjy/mquote latest
go: downloading github.com/eddycjy/mquote v0.0.0-20200220041913-e066a990ce6f
go: extracting github.com/eddycjy/mquote v0.0.0-20200220041913-e066a990ce6f

Просмотр файла go.mod

При инициализации проекта будет сгенерирован файл go.mod, который является наиболее важным идентификатором, необходимым для включения проекта модулей Go.Это также идентификатор, когда значение GO111MODULE равно auto, который описывает текущий проект (т.е. текущий модуль).Метаинформация, каждая строка начинается с глагола.

После того, как мы только что проинициализировались и просто подтянулись, снова смотрим файл go.mod, основное содержимое такое:

module github.com/eddycjy/module-repo

go 1.13

require (
	github.com/eddycjy/mquote v0.0.0-20200220041913-e066a990ce6f
)

Для дальнейшего объяснения мы моделируем ссылку следующим образом:

module github.com/eddycjy/module-repo

go 1.13

require (
    example.com/apple v0.1.2
    example.com/banana v1.2.3
    example.com/banana/v2 v2.3.4
    example.com/pear // indirect
    example.com/strawberry // incompatible
)

exclude example.com/banana v1.2.4
replace example.com/apple v0.1.2 => example.com/fried v0.1.0 
replace example.com/banana => example.com/fish
  • модуль: используется для определения пути к модулю текущего проекта.
  • go: используется для определения версии текущего модуля на языке Go. Значением является версия, когда модуль был инициализирован. В настоящее время это только функция идентификации.
  • require: используется для установки конкретной версии модуля.
  • exclude: используется для исключения использования определенной версии модуля.
  • replace: Используется для замены одной версии модуля другой версией модуля.

Также вы найдетеexample.com/pearЗа ним будет стоять косвенный флаг.Непрямой флаг указывает на то, что модуль является косвенной зависимостью, то есть в операторе импорта в текущем приложении не найдена явная ссылка на этот модуль.Возможно, что вы вручнуюgo getВытащенный, он также может зависеть от модуля, от которого вы зависите, есть несколько ситуаций.

Посмотреть файл go.sum

После первого извлечения зависимостей модуля вы найдете дополнительный файл go.sum, в котором подробно перечислены все версии модуля, прямо или косвенно зависящие от текущего проекта, и указано хеш-значение SHA-256 этих версий модуля. В случае, если Go гарантирует, что версии тех модулей, от которых зависит проект, не будут изменены в будущих операциях.

github.com/eddycjy/mquote v0.0.1 h1:4QHXKo7J8a6J/k8UA6CiHhswJQs0sm2foAQQUq8GFHM=
github.com/eddycjy/mquote v0.0.1/go.mod h1:ZtlkDs7Mriynl7wsDQ4cU23okEtVYqHwl7F1eDh4qPg=
github.com/eddycjy/mquote/module/tour v0.0.1 h1:cc+pgV0LnR8Fhou0zNHughT7IbSnLvfUZ+X3fvshrv8=
github.com/eddycjy/mquote/module/tour v0.0.1/go.mod h1:8uL1FOiQJZ4/1hzqQ5mv4Sm7nJcwYu41F3nZmkiWx5I=
...

Мы видим, что путь к модулю может иметь следующие два типа:

github.com/eddycjy/mquote v0.0.1 h1:4QHXKo7J8a6J/k8UA6CiHhswJQs0sm2foAQQUq8GFHM=
github.com/eddycjy/mquote v0.0.1/go.mod h1:ZtlkDs7Mriynl7wsDQ4cU23okEtVYqHwl7F1eDh4qPg=

h1 заключается в том, что после того, как модули Go распаковывают zip-файл версии целевого модуля, по очереди хешируют все файлы в пакете, а затем объединяют их результаты хеширования в общее значение хеш-функции в соответствии с фиксированным форматом и алгоритмом.

А хеш h1 и хэш go.mod либо существуют одновременно, либо существует только хеш go.mod. При каких обстоятельствах не будет хэша h1, то есть когда Go подумает, что некая версия модуля не будет использоваться, его хеш h1 будет опущен, и хэша h1 не будет, только хэш go.mod Есть ситуация .

Посмотреть глобальный кеш

Мы только что успешноgithub.com/eddycjy/mquoteМодуль извлекается, а извлеченный результат кэшируется в$GOPATH/pkg/modи$GOPATH/pkg/sumdbкаталог, находясь вmodкаталог будетgithub.com/foo/barФормат сохраняется следующим образом:

mod
├── cache
├── github.com
├── golang.org
├── google.golang.org
├── gopkg.in
...

Следует отметить, что только одна копия данных одной и той же версии модуля кэшируется и используется всеми другими модулями. Если вы хотите очистить все кешированные данные версии модуля, вы можете выполнитьgo clean -modcacheЗаказ.

go get поведение в Go Modules

При извлечении зависимостей проекта вы обнаружите, что процесс извлечения разделен на три этапа, а именно поиск (обнаружение), загрузка (загрузка) и извлечение (извлечение), а информация о извлечении разделена на три абзаца содержания.

image

Следует отметить, что время фиксации извлеченной версии основано на часовом поясе UTC, а не на местном часовом поясе, и мы обнаружим, что мыgo getВерсия, извлеченная командой, — v0.0.0, потому что мы выполняем ее напрямую.go get -uВ полученной версии не указывается никакой информации о версии, и модули Go выбираются сами по себе в соответствии с внутренними правилами.

Вытягивающее поведение go get

только что мы использовалиgo getКоманда извлекает новую зависимость, затемgo getКакие функции предоставляются?

Заказ эффект
go get Зависимости извлечения будут выполнять определенные извлечения (обновления) и не будут обновлять другие зависимые модули.
go get -u Обновление существующей зависимости приведет к обновлению всех других модулей, от которых она зависит, за исключением самого себя.
go get -u -t ./... Обновите все прямо и косвенно зависимые версии модулей, в том числе используемые в модульных тестах.

Поэтому я хочу выбрать, как должна выполняться конкретная версия, следующим образом:

Заказ эффект
go get golang.org/x/text@latest Вытяните последнюю версию, если есть тег, он будет использоваться первым.
go get golang.org/x/text@master Вытащите последний коммит из ветки master.
go get golang.org/x/text@v0.3.2 Вытащите коммит с тегом v0.3.2.
go get golang.org/x/text@342b2e Вытащите коммит с хешем 342b231, который в итоге будет преобразован в v0.3.2.

Выбор версии для go get

Давайте посмотрим, что мы вытащилиgo get github.com/eddycjy/mquote, результатv0.0.0-20200220041913-e066a990ce6f, согласно вышеизложенномуgo getС точки зрения поведения у вас могут быть еще некоторые сомнения, т.go getЕсли версия не указана, каково правило выбора ее версии и почемуgo getвытащилv0.0.0, когда он будет тянуть теги с нормальными номерами версий? На самом деле это необходимо различать два случая, а именно:

  1. Вытащенные модули имеют теги выпуска:
    • Если есть только один модуль, возьмите тег с наибольшим основным номером версии.
    • Если есть несколько модулей, рассчитайте соответствующий путь модуля и возьмите тег с наибольшим номером основной версии (путь модуля тега подмодуля будет иметь требование префикса)
  2. Вытащенный модуль не имеет опубликованных тегов:
    • По умолчанию берется хэш последнего коммита ветки master.

Нет размещенных тегов

Так почему тянутьv0.0.0Ну, потому чтоgithub.com/eddycjy/mquoteТеги не были опубликованы, а именно:

image

Поэтому по умолчанию используется время коммита и хэш последнего коммита основной ветки, то есть20200220041913-e066a990ce6f, что относится ко второму случаю.

Имеет теги выпуска

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

image

В этом проекте у нас всего два тега: v0.0.1 и module/tour/v0.0.1. В этот момент вы можете задаться вопросом, почемуmodule/tour/v0.0.1Какой смысл в таком "странном" теге?

На самом деле, это теговое представление модулей Go в нескольких модулях одного и того же проекта.Основная структура каталогов:

mquote
├── go.mod
├── module
│   └── tour
│       ├── go.mod
│       └── tour.go
└── quote.go

можно увидеть вmquoteВ корневом каталоге этого проекта есть файл go.mod, а вmodule/tourВ каталоге также есть файл go.mod, и соответствующая связь между импортом модуля и информацией о версии выглядит следующим образом:

tag путь импорта модуля значение
v0.0.1 github.com/eddycjy/mquote v 0.0.1 версия проекта mquote
module/tour/v0.01 github.com/eddycjy/mquote/module/tour Версия v0.0.1 модуля/тура подмодуля проекта mquote

В основные модули и подмодули

В сочетании с вышеуказанным содержимым, если вы вытащите основной модуль, выполните следующую команду, как обычно:

$ go get github.com/eddycjy/mquote@v0.0.1
go: finding github.com/eddycjy/mquote v0.0.1
go: downloading github.com/eddycjy/mquote v0.0.1
go: extracting github.com/eddycjy/mquote v0.0.1

Если вы хотите вытащить подмодуль, выполните следующую команду:

$ go get github.com/eddycjy/mquote/module/tour@v0.0.1
go: finding github.com/eddycjy/mquote/module v0.0.1
go: finding github.com/eddycjy/mquote/module/tour v0.0.1
go: downloading github.com/eddycjy/mquote/module/tour v0.0.1
go: extracting github.com/eddycjy/mquote/module/tour v0.0.1

Мы сравним тягу основного модуля и субмодуля, вы обнаружите, что тяга субмодуля сделает еще один шаг, сначала найдетgithub.com/eddycjy/mquote/module, а затем продолжить расчет и, наконец, вытащитьmodule/tour.

Описание пути импорта для модулей Go

Путей импорта для разных версий

В предыдущем извлечении и ссылке модуля вы обнаружите, что наш путь импорта модуляgithub.com/eddycjy/mquoteиgithub.com/eddycjy/mquote/module/tour, вроде ничего особенного.

На самом деле это не так, на самом деле модули Go опускают номер версии, когда номер основной версии v0 и v1, а когда номер основной версии v2 и выше, номер основной версии нужно явно указывать, иначе будет быть конфликты, тег и модуль. Примерное соотношение путей импорта выглядит следующим образом:

tag путь импорта модуля
v0.0.0 github.com/eddycjy/mquote
v1.0.0 github.com/eddycjy/mquote
v2.0.0 github.com/eddycjy/mquote/v2
v3.0.0 github.com/eddycjy/mquote/v3

Проще говоря, когда номера основных версий v0 и v1, нет необходимости включать информацию об основной версии в путь импорта модуля, а после версии v1, то есть из v2, необходимо добавить номер основной версии в конец пути импорта модуля. , его необходимо привести к следующему формату при цитировании:

import (
    "github.com/eddycjy/mquote/v2/example"
)

Также игнорирование номеров основных версий v0 и v1 является обязательным (не обязательным), поэтому для каждого пакета существует только один явный и канонический путь импорта.

Зачем игнорировать основные номера версий для v0 и v1

  1. Причина пропуска версии v1 в пути импорта: учитывая, что многие разработчики создают пакеты, которые никогда не изменяются после достижения версии v1, что официально поощряется, не думайте, что всех этих разработчиков следует выпускать, когда они не намерены чтобы выпустить версию v2.Вынужден иметь явный суффикс v1, что сделало бы v1 "шумным" и бессмысленным.

  2. Причина, по которой версии v0 исключены из пути импорта, заключается в том, что эти версии v0 вообще не имеют гарантий совместимости в соответствии со спецификацией Semantic Versioning. Требование явного идентификатора версии v0 мало что дает для обеспечения совместимости.

Семантическое управление версиями для модулей Go

Мы продолжаем ссылаться на номера версий при использовании модулей Go, которые по сути называются «семантической версией», предполагая, что номер нашей версии — v1.2.3, как показано ниже:

image

Его формат версии — «основной номер версии. дополнительный номер версии. номер редакции», а правила увеличения номеров версий следующие:

  1. Основной номер версии: когда вы вносите несовместимое изменение API.
  2. Второстепенный номер версии: Когда вы делаете функциональное дополнение для обратной совместимости.
  3. Номер редакции: когда вы вносите исправления для проблем обратной совместимости.

Предполагая, что вы являетесь первым номером версии или особым случаем, вы можете добавить информацию о версии в конце «основной номер версии. Дополнительный номер версии. Номер редакции» в качестве расширения следующим образом:

image

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

Выбор минимальной версии для Go Modules

Теперь у нас есть модуль и выпущенный тег, но модуль часто зависит от многих других модулей, и разные модули могут зависеть от разных версий одного и того же модуля, когда они зависят, как показано на следующем рисунке (от Расса Кокса):

image

В приведенных выше зависимостях модуль A зависит от модуля B и модуля C, а модуль B зависит от модуля D, модуль C зависит от модулей D и F, модуль D зависит от модуля E, а разные версии одного и того же модуля также зависят от соответствующие разные версии модулей. Итак, как модули Go выбирают версию в настоящее время и какую версию выбираете вы?

Согласно предложению, мы знаем, что модули Go будут сортировать список зависимых версий каждого модуля и, наконец, получат список сборки, как показано ниже (от Расса Кокса):

image

Мы видим приблизительный список и окончательный список. Разница между ними заключается в повторной ссылке на модуль D (v1.3, v1.4). В окончательном списке используется версия модуля D версии 1.4. Основные причины:

  1. Семантический контроль версий: поскольку все изменения версии v1.3 и v1.4 модуля D являются незначительными изменениями номера версии, и в соответствии с ограничениями семантической версии v1.4 должна быть обратно совместима с версией v1.3, поэтому никаких критических изменений считаются, то есть совместимыми.

  2. Спецификация пути импорта модуля: номер основной версии отличается, и путь импорта модуля отличается.Поэтому, если есть несовместимость, номер основной версии изменится, и путь импорта модуля, естественно, изменится, поэтому он не будет таким же, как первый пункт, конфликтующие основы.

Вы хотите отправить файл go.sum?

Теоретически файлы go.mod и go.sum должны быть зафиксированы в вашем репозитории Git.

Предположим, мы не загружаем файл go.sum, это заставит всех выполнять команды, относящиеся к модулям Go, и будет сгенерирован новый файл go.sum, то есть он снова будет подтянут вверх по течению, и он может быть подделан с при повторном извлечении.Да, будет большая угроза безопасности, и содержимое проверки с базовой версией (первое отправленное лицо, ожидаемая версия) будет потеряно, поэтому необходимо отправить файл go.sum.

Суммировать

До сих пор мы представили прошлое и настоящее модулей Go, базовое использование и режим модулей Go.go getПреобразование поведения команд, и мы даем общее введение в общие пути импорта нескольких версий, семантический контроль версий и правила выбора минимальной версии нескольких модулей.

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

мой публичный аккаунт

image

Ссылаться на

Категории