トップレベルとサブモジュールが異なるバージョンとしてインポートされている場合に、競合する Go モジュールの依存関係を解決するにはどうすればよいですか?

トップレベルのモジュールとサブモジュールが異なるバージョンとしてインポートされる場合に競合する Go モジュールの依存関係を解決する

トップレベルのモジュールとサブモジュールが異なるバージョンとしてインポートされている場合、Go モジュールの依存関係が競合を引き起こすことがあります。モジュールとそのサブモジュールの 1 つは、異なるバージョンとして個別にインポートされます。この問題を調査して解決策を見つけてみましょう。

問題の概要

以下の go.mod ファイルに示すように、プロジェクト内に 2 つの依存関係がある場合、go mod download コマンドを実行すると、共有サブモジュールの異なるバージョンがダウンロードされる可能性があります。

module github.com/test-org/test-repo

go 1.12

require (
    github.com/foo/bar v1.0.0
    github.com/raz/mataz v1.0.0
)

Go ツールが不確実であるため、コード内でサブモジュールをインポートするときにあいまいなインポート エラーが発生する可能性があります。どのバージョンを選択するか。

解決策

依存関係の 1 つがサブモジュールの pre-go-modules バージョンを参照している場合に問題が発生します。リポジトリ全体のこのブラック ボックス インポートは、サブモジュールへのモジュール参照と競合します。

この競合を解決するには、共有依存関係への参照が go-module 対応バージョンを使用するように強制できます。次の行を go.mod ファイルに追加します:

replace (
    github.com/shared/dependency => github.com/shared/dependency v1.2.0
)

指定されたバージョン (この例では v1.2.0) が go-module 対応であることを確認してください (go.mod ファイルがある)。

このソリューションが機能するのは、共有依存関係へのすべての参照でモジュール バージョンが使用されることが保証され、あいまいなインポート エラーの原因となったブラック ボックス インポートの競合が排除されるためです。

以上がトップレベルとサブモジュールが異なるバージョンとしてインポートされている場合に、競合する Go モジュールの依存関係を解決するにはどうすればよいですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。