Показаны сообщения с ярлыком файл go.mod в Golang. Показать все сообщения
Показаны сообщения с ярлыком файл go.mod в Golang. Показать все сообщения

среда, 28 апреля 2021 г.

Обзор файла go.mod

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

Эти свойства включают:

  • Путь к текущему модулю. Это должно быть место, из которого модуль может быть загружен инструментами Go, например расположение репозитория кода модуля. Он служит уникальным идентификатором в сочетании с номером версии модуля. Это также префикс пути к пакету для всех пакетов в модуле.
  • Минимальная версия Go, необходимая для текущего модуля.
  • Список минимальных версий других модулей, необходимых для текущего модуля.
  • Инструкции, необязательно, для замены необходимого модуля другой версией модуля или локальным каталогом, или для исключения определенной версии необходимого модуля.

Go создает файл go.mod, когда вы запускаете команду go mod init. В следующем примере создается файл go.mod, устанавливая путь к модулю модуля на example.com/mymodule:

$ go mod init example.com/mymodule

Используйте команды go для управления зависимостями. Команды гарантируют, что требования, описанные в вашем файле go.mod, остаются согласованными, а содержимое вашего файла go.mod является действительным. Эти команды включают команды go get and go mod tidy и go mod edit.

Вы можете получить справку из командной строки, набрав go help имя-команды, как в случае с go help mod tidy.

Пример

Файл go.mod включает директивы, показанные в следующем примере. Они описаны в этом посте.

module example.com/mymodule

go 1.14

require (
    example.com/othermodule v1.2.3
    example.com/thismodule v1.2.3
    example.com/thatmodule v1.2.3
)

replace example.com/thatmodule => ../thatmodule
exclude example.com/thismodule v1.3.0

module

Объявляет путь к модулю модуля, который является уникальным идентификатором модуля (в сочетании с номером версии модуля). Он становится префиксом импорта для всех пакетов, содержащихся в модуле.

Синтаксис

module module-path

module-path

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

Примеры

В следующих примерах example.com заменяется доменом репозитория, из которого можно загрузить модуль.

  • Объявление модуля для модуля v0 или v1:

    module example.com/mymodule
    

  • Путь к модулю для модуля v2:

    module example.com/mymodule/v2
    

Заметки

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

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

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

Например, если вы разрабатываете в каталоге stringtools, ваш временный путь к модулю может быть example.com/stringtools, как в следующем примере:

go mod init example.com/stringtools

go

Указывает, что модуль был написан с учетом семантики версии Go, указанной в директиве.

Синтаксис

go minimum-go-version

minimum-go-version

Минимальная версия Go, необходимая для компиляции пакетов в этом модуле.

Примеры

Модуль должен работать на Go версии 1.14 или новее:

go 1.14

Заметки

Директива go изначально предназначалась для поддержки обратно несовместимых изменений языка Go. С момента появления модулей несовместимых языковых изменений не было, но директива go по-прежнему влияет на использование новых языковых функций:

  • Для пакетов в модуле компилятор отклоняет использование языковых функций, представленных после версии, указанной в директиве go. Например, если у модуля есть директива go 1.12, его пакеты могут не использовать числовые литералы, такие как 1_000_000, которые были введены в Go 1.13.
  • Если более старая версия Go собирает один из пакетов модуля и обнаруживает ошибку компиляции, в сообщении об ошибке указывается, что модуль был написан для более новой версии Go. Например, предположим, что у модуля есть версия 1.13, а в пакете используется числовой литерал 1_000_000. Если этот пакет собран с Go 1.12, компилятор отмечает, что код написан для Go 1.13.

Кроме того, команда go изменяет свое поведение в зависимости от версии, указанной в директиве go. Это имеет следующие эффекты:

  • В версии 1.14 или выше может быть включен автоматический вендоринг. Если файл vendor/modules.txt присутствует и согласуется с go.mod, нет необходимости явно использовать флаг -mod=vendor.
  • В версии 1.16 и выше шаблон пакетов all соответствует только пакетам, транзитивно импортированным пакетами и тестами в основном модуле. Это тот же набор пакетов, который оставлен go mod vendor с момента появления модулей. В более низких версиях all также включает пакеты тестов, импортированных пакетами в основном модуле, тесты этих пакетов и т. д.

Файл go.mod может содержать не более одной директивы go. Большинство команд добавят директиву go с текущей версией Go, если она отсутствует.

require

Объявляет модуль как зависимость, требуемую текущим модулем, указывая минимальную требуемую версию модуля.

Синтаксис

require module-path module-version

module-path

Путь к модулю модуля, обычно представляет собой объединение домена репозитория исходного кода модуля и имени модуля. Для версий модуля v2 и более поздних это значение должно заканчиваться основным номером версии, например /v2.

module-version

Версия модуля. Это может быть либо номер версии релиза, например v1.2.3, либо номер псевдо-версии, сгенерированный Go, например v0.0.0-20200921210052-fa0125251cc4.

Примеры

Требование релизной версии v1.2.3:

require example.com/othermodule v1.2.3

Требование версии, еще не имеющей тега в своем репозитории, с использованием номера псевдоверсии, сгенерированного инструментами Go:

require example.com/othermodule v0.0.0-20200921210052-fa0125251cc4

Заметки

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

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

Дополнительные сведения о номерах версий в посте нумерация версий модулей.

Дополнительные сведения об управлении зависимостями.

replace

Заменяет содержимое модуля определенной версии (или всех версий) другой версией модуля или локальным каталогом. Инструменты Go будут использовать путь замены при разрешении зависимости.

Синтаксис

replace module-path [module-version] => replacement-path [replacement-version]

module-path

Путь к заменяемому модулю.

module-version

Необязательный. Конкретная версия для замены. Если этот номер версии опущен, все версии модуля заменяются содержимым, указанным справа от стрелки.

replacement-path

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

replacement-version

Версия заменяемого модуля. Версия для замены может быть указана только в том случае, если replace-path является путем к модулю (а не локальным каталогом).

Примеры

Замена форком репозитория модуля

В следующем примере любая версия example.com/othermodule заменяется указанным форком ее кода.

require example.com/othermodule v1.2.3

replace example.com/othermodule => example.com/myfork/othermodule v1.2.3-fixed

Когда вы заменяете один путь модуля другим, не меняйте операторы импорта для пакетов в модуле, который вы заменяете.

Дополнительные сведения об использовании разветвленной копии кода модуля в посте управление зависимостями.

Замена на другой номер версии

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

require example.com/othermodule v1.2.2

replace example.com/othermodule => example.com/othermodule v1.2.3

В следующем примере версия модуля v1.2.5 заменяется версией v1.2.3 того же модуля.

replace example.com/othermodule v1.2.5 => example.com/othermodule v1.2.3

Замена местным кодом

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

require example.com/othermodule v1.2.3

replace example.com/othermodule => ../othermodule

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

require example.com/othermodule v1.2.5

replace example.com/othermodule v1.2.5 => ../othermodule

Дополнительные сведения об использовании локальной копии кода модуля в посте управление зависимостями.

Заметки

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

Используйте директивы exclude и replace для управления разрешением зависимостей во время сборки при сборке текущего модуля. Эти директивы игнорируются в модулях, зависящих от текущего модуля.

Директива replace может быть полезна в следующих ситуациях:

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

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

Дополнительные сведения о номерах версий в посте нумерация версий модулей.

exclude

Задает модуль или версию модуля, которую необходимо исключить из графа зависимостей текущего модуля.

Синтаксис

exclude module-path module-version

module-path

Путь к модулю исключаемого модуля.

module-version

Конкретная версия, которую нужно исключить.

Пример

Исключить example.com/theirmodule версии v1.3.0

exclude example.com/theirmodule v1.3.0

Заметки

Используйте директиву exclude, чтобы исключить конкретную версию модуля, которая требуется косвенно, но по какой-то причине не может быть загружена. Например, вы можете использовать ее для исключения версии модуля с недопустимой контрольной суммой.

Используйте директивы exclude и replace для управления разрешением зависимостей во время сборки при сборке текущего модуля (основного модуля, который вы создаете). Эти директивы игнорируются в модулях, зависящих от текущего модуля.

Вы можете использовать команду go mod edit, чтобы исключить модуль, как в следующем примере.

go mod edit -exclude=example.com/theirmodule@v1.3.0

Дополнительные сведения о номерах версий в посте нумерация версий модулей.


Читайте также:


понедельник, 22 февраля 2021 г.

Модули в Golang: файл go.mod, директива retract

Директива retract указывает версию или диапазон версий модуля, определенных go.mod, от которых не следует зависеть. Директива retract полезна, когда версия была опубликована преждевременно или после публикации версии была обнаружена серьезная проблема. Отозванные (Retracted) версии должны оставаться доступными в репозиториях системы контроля версий и на прокси-серверах модулей, чтобы гарантировать, что сборки, зависящие от них, не будут повреждены. Слово retract заимствовано из академической литературы: отозванная (retracted) исследовательская статья все еще доступна, но она имеет проблемы и не должна быть основой для будущей работы.

Когда версия модуля отозвана, пользователи не будут обновляться до нее автоматически с помощью go get, go mod tidy или других команд. Сборки, зависящие от отозванных версий, должны продолжать работать, но пользователи будут уведомлены об отзывах (retractions), когда они проверят наличие обновлений с помощью go list -m -u или обновят связанный модуль с помощью go get.

Чтобы отозвать версию, автор модуля должен добавить директиву retract в go.mod, а затем опубликовать новую версию, содержащую эту директиву. Новая версия должна быть выше, чем другие релизные или предварительные версии; то есть, запрос @latest версии должен разрешить новую версию до рассмотрения отзыва. Команда go загружает и применяет отзывы из версии, показанной go list -m -retracted $modpath@latest (где $modpath - это путь к модулю).

Отозванные версии скрываются из списка версий, выводимого командой go list -m -versions, если не используется флаг -retracted. Отозванные версии исключаются при разрешении запросов о версиях, таких как @>=v1.2.3 или @latest.

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

В качестве примера рассмотрим случай, когда автор модуля example.com/m случайно публикует версию v1.0.0. Чтобы предотвратить обновление пользователей до версии 1.0.0, автор может добавить две директивы retract в go.mod, а затем пометить версию 1.0.1 отзывами.

retract (
    v1.0.0 // Опубликовано случайно.
    v1.0.1 // Содержит только отзывы.
)

Когда пользователь запускает go get example.com/m@latest, команда go считывает отзывы из v1.0.1, которая теперь является самой высокой версией. И v1.0.0, и v1.0.1 отозваны, поэтому команда go обновит (или откатит!) до следующей высшей версии, возможно, v0.9.5.

Директивы retract могут быть написаны либо с одной версией (например, v1.0.0), либо с закрытым интервалом версий с верхней и нижней границами, разделенными символом [ и символом ] (например, [v1.1.0, v1.2.0]). Единая версия эквивалентна интервалу, в котором верхняя и нижняя границы совпадают. Как и другие директивы, несколько директив retract могут быть сгруппированы в блок, разделенный символом ( в конце строки и символом ) на отдельной строке.

В каждой директиве retract должен быть комментарий, объясняющий причину отзыва, хотя это не обязательно. Команда go может отображать комментарии с обоснованием в предупреждениях об отозванных версиях и в выводе go list. Обосновывающий комментарий может быть написан непосредственно над директивой retract (без пустой строки между ними) или после в той же строке. Если комментарий появляется над блоком, он применяется ко всем директивам retract внутри блока, у которых нет собственных комментариев. Комментарий-обоснование может занимать несколько строк.

RetractDirective = "retract" ( RetractSpec | "(" newline { RetractSpec } ")" ) .
RetractSpec = ( Version | "[" Version "," Version "]" ) newline .

Пример:

retract v1.0.0
retract [v1.0.0, v1.9.9]
retract (
    v1.0.0
    [v1.0.0, v1.9.9]
)

Директива retract была добавлена в Go 1.16. Go 1.15 и ниже будет сообщать об ошибке, если директива retract записана в файле go.mod главного модуля, и игнорирует директивы retract в файлах go.mod зависимостей.

Пример использования rectract - https://github.com/A1esandr/retract


Читайте также:


вторник, 9 февраля 2021 г.

Модули в Golang: файл go.mod, автоматические обновления

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

module example.com/M

require (
    example.com/A v1
    example.com/B v1.0.0
    example.com/C v1.0.0
    example.com/D v1.2.3
    example.com/E dev
)

exclude example.com/D v1.2.3

Обновление переписывает идентификаторы неканонической версии в каноническую форму semver, поэтому v1 example.com/A становится v1.0.0, а dev example.com/E становится псевдо-версией для последней фиксации в ветке dev, возможно v0.0.0-20180523231146-b3f5c0f6e5f1.

Обновление изменяет требования для соблюдения исключений, поэтому требование на исключенном example.com/D v1.2.3 обновлено для использования следующей доступной версии example.com/D, возможно, v1.2.4 или v1.3.0.

Обновление удаляет повторяющиеся или вводящие в заблуждение требования. Например, если example.com/A v1.0.0 требует example.com/B v1.2.0 и example.com/C v1.0.0, то требование go.mod о example.com/B v1.0.0 вводит в заблуждение (заменено по потребности example.com/A в v1.2.0), а его требование example.com/C v1.0.0 является избыточным (подразумевается необходимостью example.com/A в одной и той же версии), поэтому оба будут удалены. Если основной модуль содержит пакеты, которые напрямую импортируют пакеты с example.com/B или example.com/C, то требования будут сохранены, но обновлены до фактических используемых версий.

Наконец, обновление переформатирует go.mod в каноническом формате, так что будущие механические изменения приведут к минимальным различиям. Команда go не обновит go.mod, если нужны только изменения форматирования.

Поскольку граф модуля определяет значение операторов импорта, любые команды, которые загружают пакеты, также используют и поэтому обновляют go.mod, включая go build, go get, go install, go list, go test, go mod graph, go mod tidy и go mod why.

Флаг -mod=readonly запрещает командам автоматически обновлять go.mod. Однако, если команде необходимо выполнить действие, которое приведет к обновлению до go.mod, она сообщит об ошибке. Например, если go build предлагается собрать пакет, не предоставленный каким-либо модулем в списке сборки, go build сообщит об ошибке вместо поиска модуля и обновления требований в go.mod.


Читайте также:


суббота, 6 февраля 2021 г.

Модули в Golang: файл go.mod, грамматика

Синтаксис go.mod указан ниже с использованием расширенной формы Бэкуса-Наура (EBNF).

GoMod = { Directive } .
Directive = ModuleDirective |
            GoDirective |
            RequireDirective |
            ExcludeDirective |
            ReplaceDirective |
            RetractDirective .

Новые строки, идентификаторы и строки обозначаются символами новой строки, идентификатором и строкой соответственно.

Пути и версии модулей обозначаются ModulePath и Version.

ModulePath = ident | string . 
Version = ident | string .    

Директива module

Директива module определяет путь к основному модулю (main module). Файл go.mod должен содержать ровно одну директиву module.

ModuleDirective = "module" ( ModulePath | "(" newline ModulePath newline ")" newline .

Пример:

module golang.org/x/net

Директива go

Директива go устанавливает ожидаемую языковую версию для модуля. Версия должна быть действующей версией релиза Go: положительное целое число, за которым следует точка, и неотрицательное целое число (например, 1.9, 1.14).

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

Языковая версия также используется для включения функций в команде go. Например, автоматический вендоринг может быть включен в версии 1.14 или выше.

Файл go.mod может содержать не более одной директивы go. Большинство команд добавят директиву go в текущую версию Go, если она отсутствует.

GoDirective = "go" GoVersion newline .
GoVersion = string | ident .  /* действующая версия релиза */

Пример:

go 1.14

Директива require

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

Команда go автоматически добавляет // indirect комментарии для некоторых требований. // indirect комментарий указывает, что ни один пакет из требуемого модуля не импортируется напрямую каким-либо пакетом в основном (main) модуле. Команда go добавляет косвенное требование, когда выбранная версия модуля выше, чем то, что уже подразумевается (транзитивно) другими зависимостями основного модуля. Это может произойти из-за явного обновления (go get -u), удаления какой-либо другой зависимости, которая ранее накладывала требование (go mod tidy), или зависимости, которая импортирует пакет без соответствующего требования в собственном файле go.mod (например, зависимость, в которой вообще отсутствует файл go.mod).

RequireDirective = "require" ( RequireSpec | "(" newline { RequireSpec } ")" newline ) .
RequireSpec = ModulePath Version newline .

Пример:

require golang.org/x/net v1.2.3

require (
    golang.org/x/crypto v1.4.5 // indirect
    golang.org/x/text v1.6.7
)

Директива exclude

Директива exclude предотвращает загрузку версии модуля командой go. Если на исключенную версию ссылается директива require в файле go.mod, команда go выведет список доступных версий для модуля (как показано с помощью go list -m -versions) и вместо этого загрузит следующую более высокую неисключенную версию. Для этой цели рассматриваются как релизная, так и предварительная версия, но псевдо-версии - нет. Если более поздних версий нет, команда go сообщит об ошибке. Обратите внимание, что это может измениться в Go 1.16.

Директивы exclude применяются только в файле go.mod главного модуля и игнорируются в других модулях.

ExcludeDirective = "exclude" ( ExcludeSpec | "(" newline { ExcludeSpec } ")" ) .
ExcludeSpec = ModulePath Version newline .

Пример:

exclude golang.org/x/net v1.2.3

exclude (
    golang.org/x/crypto v1.4.5
    golang.org/x/text v1.6.7
)

Директива replace

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

Если версия указана слева от стрелки (=>), заменяется только эта конкретная версия модуля; другие версии будут доступны в обычном режиме. Если левая версия не указана, заменяются все версии модуля.

Если путь справа от стрелки является абсолютным или относительным (начинается с ./ или ../), он интерпретируется как локальный путь к корневому каталогу заменяющего модуля, который должен содержать файл go.mod. В этом случае заменяющая версия не указывается.

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

Независимо от того, указана ли замена с локальным путем или путем к модулю, если у заменяющего модуля есть файл go.mod, его директива модуля должна соответствовать пути модуля, который он заменяет.

Директивы replace применяются только в файле go.mod главного модуля и игнорируются в других модулях.

ReplaceDirective = "replace" ( ReplaceSpec | "(" newline { ReplaceSpec } ")" newline ")" ) .
ReplaceSpec = ModulePath [ Version ] "=>" FilePath newline
            | ModulePath [ Version ] "=>" ModulePath Version newline .
FilePath = /* относительный или абсолютный путь к файлу, зависящий от платформы */

Пример:

replace golang.org/x/net v1.2.3 => example.com/fork/net v1.4.5

replace (
    golang.org/x/net v1.2.3 => example.com/fork/net v1.4.5
    golang.org/x/net => example.com/fork/net v1.4.5
    golang.org/x/net v1.2.3 => ./fork/net
    golang.org/x/net => ./fork/net
)


Читайте также:


четверг, 4 июля 2019 г.

Вспомогательные темы инструмента go: файл go.mod

go help go.mod

Версия модуля определяется деревом исходных файлов с файлом go.mod в его корне. Когда команда go выполняется, она просматривает текущий каталог, а затем последующие родительские каталоги, чтобы найти go.mod, отмечающий корень основного (текущего) модуля.

Сам файл go.mod ориентирован на строки, с // комментариями, но без /* */ комментариев. Каждая строка содержит одну директиву, состоящую из глагола, за которым следуют аргументы. Например:

module my/thing
go 1.12
require other/thing v1.0.2
require new/thing/v2 v2.3.4
exclude old/thing v1.2.3
replace bad/thing v1.4.5 => good/thing v1.4.5

Глаголы:

module  чтобы определить путь модуля;
go      чтобы установить ожидаемую версию языка;
require требовать определенный модуль в данной версии 
        или новее;
exclude чтобы исключить конкретную версию модуля 
        из использования;
replace чтобы заменить версию модуля другой 
        версией модуля.

exclude и replace применяются только в go.mod основного модуля и игнорируются в зависимостях.

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

require (
    new/thing v2.3.4
    old/thing v1.2.3
)

Файл go.mod предназначен как для непосредственного редактирования, так и для удобного обновления инструментами. Команда go mod edit может использоваться для анализа и редактирования файла go.mod из программ и инструментов.

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

module M

require (
        A v1
        B v1.0.0
        C v1.0.0
        D v1.2.3
        E dev
)

exclude D v1.2.3

Обновление переписывает неканонические идентификаторы версий в форму semver, поэтому версия v1 для A становится v1.0.0, а dev для E становится псевдо-версией для последнего коммита в ветви dev, возможно, v0.0.0-20180523231146-b3f5c0f6e5f1.

Обновление изменяет требования для соблюдения исключений, поэтому требование исключенной версии D v1.2.3 обновляется для использования следующей доступной версии D, возможно, версии D v1.2.2 или D v1.3.3.

Обновление устраняет избыточные или вводящие в заблуждение требования. Например, если для A v1.0.0 требуется B v1.2.0 и C v1.0.0, то требование go.mod для B v1.0.0 вводит в заблуждение (заменено потребностью A в v1.2.0) и требованием C v1.0.0 является избыточным (подразумевается потребность A в одной и той же версии), поэтому оба будут удалены. Если модуль M содержит пакеты, которые напрямую импортируют пакеты из B или C, то требования будут сохранены, но обновлены до фактических используемых версий.

Наконец, обновление переформатирует go.mod в каноническое форматирование, так что будущие механические изменения приведут к минимальным различиям.

Поскольку граф модуля определяет значение операторов импорта, любые команды, которые загружают пакеты, также используют и, следовательно, обновляют go.mod, включая go build, go get, go install, go list, go test, go mod graph, go mod tidy и go mod why.


Читайте также: