web-dev-qa-db-ja.com

Goモジュール:必要なパッケージの正しい擬似バージョン(vX.Y.Z- <timestamp>-<commit>)を見つける

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 for a 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コミットIDのようなもので構成されています。

これらのバージョン文字列をどのように把握しますか?これらのgolang.org/xパッケージは、ある時点でセマンティックバージョニングに従ってバージョン化されると思いますが、go modを実際に試すには、それらを理解する必要がありますnow

7
Patrick Bucher

今、私はドキュメントでもう少し読みます(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仕事。

1
Patrick Bucher

v0.0.0-20180906233101-161cd47e91fdという形式のバージョンは、gitリポジトリにタグ付きバージョンがないことを意味します。したがって、go modは、最新のコミット時刻とコミットハッシュのプレフィックスに基づいて生成します。

正しいgo.modファイルを取得するには、次のコマンドを使用して開始します(go 1.11を想定)。

go mod init yourmodulename

または、次を含む空のgo.modファイルを作成します。

module yourmodulename

次にgo mod tidyを実行します。これにより、すべての依存関係が検出され、不足しているものが追加され、未使用の依存関係が削除されます。

5
nijm

著者はv0.0.0-20170922011244-0744d001aa84のようなバージョン文字列を使用しています。これは、semver指示v0.0.0、タイムスタンプ、およびgitコミットIDのようなもので構成されています。

これらのバージョン文字列をどのように把握しますか?

pseudo-versions と呼ばれる複雑なバージョン文字列を手動で把握する必要はありません。

毎日のワークフロー

典型的な毎日のワークフローは次のとおりです。

  • 必要に応じて、.goコードにimportステートメントを追加します。
  • go buildgo test、またはgo mod tidyなどの標準コマンドは、インポートを満たすために必要に応じて新しい依存関係を自動的に追加します(go.modの更新と新しい依存関係のダウンロード)。デフォルトでは、新しい直接依存関係の@latestバージョンが使用されます。
  • 必要に応じて、次のようなコマンドを使用して、より具体的なバージョンの依存関係を選択できます。
    • go get [email protected]
    • go get foo@e3702bed2
    • go get foo@latest
    • go get foo@branch
    • または、go.modを直接編集します。

特定のコミット(@e3702bed2など)やブランチの最新のコミット(@masterなど)を要求する場合でも、これらの例のいずれかで独自に擬似バージョンを作成する必要はないことに注意してください。

go.modにはいつ擬似バージョンが表示されますか?

v1.2.3v1.2.4-beta-1などの先頭にvが付いた有効な semver タグに解決されるバージョンになった場合、そのsemverタグはgo.modファイルに記録されます。バージョンに有効なsemverタグがない場合、代わりにgo.modなどのv0.0.0-20171006230638-a6e239ea1c69ファイルに pseudo-version として記録されます。これには、バージョンセクション、コミットタイムスタンプ、およびコミットハッシュが含まれます。

特定のケースでは、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コマンドは modulesクエリを変換するため 必要に応じて、対応する擬似バージョンにgo get golang.org/x/net/html@0744d001aa84などを追加し、結果をgo.modに記録します。

なぜ擬似バージョン形式が選択されたのですか?

擬似バージョン形式は、標準 semver の順序に基づいて、すべてのバージョンにわたって単純な合計順序を提供するのに役立ちます。別のコミットよりも「後」、または実際のsemverタグが別のコミットよりも「後」と見なされるかどうか。

依存関係バージョンの制御

上記のすべての詳細については、Goモジュールwikiの 「依存関係をアップグレードおよびダウングレードする方法」 セクションをご覧ください。公式ドキュメント。

1
typical182