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。
今、私はドキュメントでもう少し読みます(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
仕事。
v0.0.0-20180906233101-161cd47e91fd
という形式のバージョンは、gitリポジトリにタグ付きバージョンがないことを意味します。したがって、go mod
は、最新のコミット時刻とコミットハッシュのプレフィックスに基づいて生成します。
正しいgo.mod
ファイルを取得するには、次のコマンドを使用して開始します(go 1.11を想定)。
go mod init yourmodulename
または、次を含む空のgo.modファイルを作成します。
module yourmodulename
次にgo mod tidy
を実行します。これにより、すべての依存関係が検出され、不足しているものが追加され、未使用の依存関係が削除されます。
著者はv0.0.0-20170922011244-0744d001aa84のようなバージョン文字列を使用しています。これは、semver指示v0.0.0、タイムスタンプ、およびgitコミットIDのようなもので構成されています。
これらのバージョン文字列をどのように把握しますか?
pseudo-versions と呼ばれる複雑なバージョン文字列を手動で把握する必要はありません。
典型的な毎日のワークフローは次のとおりです。
.go
コードにimportステートメントを追加します。go build
、go 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.3
やv1.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の 「依存関係をアップグレードおよびダウングレードする方法」 セクションをご覧ください。公式ドキュメント。