Go Modules: выяснение правильной псевдо-версии (vX.Y.Z- <timestamp>- <commit>) необходимого пакета

Question

Я пробую модули Go. Мой проект требует библиотеки golang.org/x/net/html, поэтому я определил этот файл go.mod:

module github.com/patrickbucher/prettyprint

require golang.org/x/net/html

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

package main

import (
        "fmt"
        "log"
        "os"

        "golang.org/x/net/html"
)

func main() {
        doc, err := html.Parse(os.Stdin)
        if err != nil {
                log.Fatal(err)
        }
        fmt.Println(doc)
}

Когда я запускаю go build, я получаю это сообщение об ошибке:

go: errors parsing go.mod:
~/prettyprint/go.mod:3: usage: require module/path v1.2.3

Очевидно, я пропустил номер версии. Но какой взять? Я наткнулся на статью под названием Takig Go Modules для Spin , где я нашел пример go.mod файла, содержащего ссылки на golang.org/x пакетов:

module github.com/davecheney/httpstat

require (
        github.com/fatih/color v1.5.0
        github.com/mattn/go-colorable v0.0.9
        github.com/mattn/go-isatty v0.0.3
        golang.org/x/net v0.0.0-20170922011244-0744d001aa84
        golang.org/x/sys v0.0.0-20170922123423-429f518978ab
        golang.org/x/text v0.0.0-20170915090833-1cbadb444a80
)

Автор использует строки версий, такие как v0.0.0-20170922011244-0744d001aa84, состоящие из индикации semver v0.0.0, отметки времени и чего-то похожего на идентификатор git commit.

Как мне определить эти строки версий? Я полагаю, что в какой-то момент эти golang.org/x пакеты будут версионированы в соответствии с семантическим версионированием, но для того, чтобы действительно попробовать go mod, мне нужно выяснить эти сейчас .

Answer 1

Версия формы v0.0.0-20180906233101-161cd47e91fd означает, что в репозитории git нет помеченных версий. Таким образом, go mod генерирует единицу на основе последнего времени коммита и префикса хэша коммита.

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

go mod init yourmodulename

Или создайте пустой файл go.mod, который просто содержит следующее:

module yourmodulename

затем запустите go mod tidy, он найдет все зависимости, добавит отсутствующие и удалит неиспользуемые зависимости.

Answer 2

Автор использует строки версий, такие как v0.0.0-20170922011244-0744d001aa84, состоящие из индикации semver v0.0.0, метки времени и чего-то, что выглядит как идентификатор коммита git.

Как мне определить эти строки версий?

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

Ежедневный рабочий процесс

Ваш типичный ежедневный рабочий процесс может быть:

• При необходимости добавьте операторы импорта в код .go.
• Стандартные команды, такие как go build, go test или go mod tidy, будут автоматически добавлять новые зависимости по мере необходимости для удовлетворения импорта (обновление go.mod и загрузка новых зависимостей). По умолчанию будет использоваться @latest версия новой прямой зависимости.
• При необходимости более конкретные версии зависимостей могут быть выбраны с помощью таких команд, как:
  • go get foo@v1.2.3
  • go get foo@e3702bed2
  • go get foo@latest
  • go get foo@branch
  • или путем редактирования go.mod напрямую.

Обратите внимание, что вам не нужно было предлагать псевдо-версию самостоятельно в любом из этих примеров, даже при запросе определенного коммита (например, @e3702bed2) или самого последнего коммита в ветке (например, @master).

Когда я вижу псевдо-версии в моем go.mod?

Если в итоге вы получите версию, которая разрешается в действительный тег semver с ведущим v, например v1.2.3 или v1.2.4-beta-1, то этот тег semver будет записан в вашем go.mod файл. Если версия не имеет допустимого тега semver, она будет записана как псевдо-версия в ваш файл go.mod, например, v0.0.0-20171006230638-a6e239ea1c69, который включает в себя раздел версии, коммит метка времени и хеш коммита.

В вашем конкретном случае, golang.org/x/net/html не имеет никаких тегов semver, что означает, что вы делаете go get golang.org/x/net/html@latest, или go get golang.org/x/net/html@0744d001aa84, или просто делаете go build после первого включения import "golang.org/x/net/html" в ваш файл .go , тогда golang.org/x/net/html будет записан в вашем go.mod как псевдо-версия, но учтите, что вам не нужно было самостоятельно определять сложную строку (поскольку команда go переводит при необходимости модуль запрашивает , например, go get golang.org/x/net/html@0744d001aa84, в соответствующую псевдо-версию и записывает результат в go.mod).

Почему был выбран формат псевдо-версии?

Формат псевдо-версии помогает обеспечить простой общий порядок во всех версиях на основе стандартного порядка semver , что упрощает рассуждение о том, какой коммит будет считаться «более поздним», чем другой коммит, или фактический тег semver считается «более поздним», чем отдельный коммит.

Управление версиями зависимостей

Подробнее обо всем вышеперечисленном можно прочитать в разделе «Как обновить и понизить зависимость» вики-модуля Go Modules, который также содержит дополнительные ссылки на официальную документацию.

Answer 3

Теперь я читаю немного дальше в документации (go help modules) и наткнулся на go mod tidy:

Команда 'go mod tidy' создает это представление, а затем добавляет все отсутствующие Требования к модулю и удаляет ненужные.

Поэтому, когда я оставляю требование на golang.org/x/net/html и сокращаю свой файл go.mod до этого:

module github.com/patrickbucher/prettyprint

И затем запустите go mod tidy, тогда правильно вычисляется требование с номером версии на основе пути импорта в моем исходном коде , и, таким образом, go.mod становится:

module github.com/patrickbucher/prettyprint

require golang.org/x/net v0.0.0-20180906233101-161cd47e91fd

Теперь оба go list и go build работают.