Go モジュール: GOPATH からのオール・オア・ナッシングへの移行?

プライベート リポジトリの Go モジュールと Gopath について

内部コードベースを dep から go モジュールに移行する場合、特定の考慮事項が発生します。この記事では、特にプライベート リポジトリと gopath に関連して、go モジュールを使用することの期待と結果について詳しく説明します。

Go モジュールと Gopath

Go によるとプロジェクトアーキテクトにとって、「ドットなし」パス (先行ドットのない) は標準ライブラリ専用です。内部的に開発された依存関係では、この表記法を使用しないでください。

プロジェクトが go モジュールの使用に移行したら、モジュール システムを完全に受け入れる必要があります。その後、gopath は機能的にモジュール キャッシュと同一になります。

モジュールとプライベート リポジトリの結果

モジュールへのこの移行では、プライベート リポジトリを介して依存関係を管理する必要があります。その結果、開発者は次のような結果に直面する可能性があります:

• リモート依存関係の反復: 開発者は、プライベート モジュールの依存関係を反復するために、変更をリモート リポジトリにプッシュおよびプルする必要がある場合があります。
• リポジトリのマージ: あるいは、開発者はすべてのリポジトリをマージできます

主な前提

Go モジュール プロジェクト内のすべての依存関係はモジュール システムを通じて解決される必要があるという前提は次のとおりです。正しい。 gopath は、ダウンロードされたモジュールのキャッシュとしてのみ機能します。

質問: go モジュールはオール オアナッシングですか?

はい、go モジュールはオール オアナッシングです。 。プロジェクトがモジュールを採用したら、すべての依存関係をモジュール化する必要があります。 gopath は、ダウンロードされたモジュールのキャッシュとしてのみその重要性を保持します。

Gopath から依存関係を明示的に解決する

依存関係を解決する必要があることを明示的に示す方法はありません。

追加インサイト

• プログラムを gopath の外に移動しても問題は解決しません。
• mylib ディレクトリで 'go mod init' を実行しても状況には影響しません。
• $GOPROXY を利用すると、プライベート モジュールを使用したオフライン開発が容易になります依存関係。

以上がGo モジュール: GOPATH からのオール・オア・ナッシングへの移行?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。