モジュールソースの管理

他の開発者が使用できるように公開するモジュールを開発する際には、このトピックで説明されているリポジトリの規則に従うことで、他の開発者がモジュールをより簡単に使用できるようにすることができます。

このトピックでは、モジュールリポジトリを管理する際に実行できる操作について説明します。バージョンからバージョンへの修正時に実行するワークフローステップのシーケンスについては、「モジュールのリリースとバージョン管理ワークフロー」を参照してください。

ここで説明されている規則の一部はモジュールで必須ですが、その他はベストプラクティスです。このコンテンツは、依存関係の管理で説明されている基本的なモジュールの使用に関する実践に精通していることを前提としています。

Goは、モジュールの公開に次のリポジトリをサポートしています:Git、Subversion、Mercurial、Bazaar、Fossil。

モジュール開発の概要については、「モジュールの開発と公開」を参照してください。

Goツールが公開されたモジュールを見つける方法

Goの分散型システムでは、モジュールを公開し、そのコードを取得できますが、コードはリポジトリに残したままです。Goツールは、リポジトリパスとリポジトリタグを使用してモジュールの名前とバージョン番号を示す命名規則に依存します。リポジトリがこれらの要件を満たしている場合、go getコマンドなどのGoツールによって、モジュールコードをリポジトリからダウンロードできます。

開発者がgo getコマンドを使用して、コードがインポートするパッケージのソースコードを取得すると、コマンドは次の処理を実行します。

  1. Goソースコードのimport文から、go getはパッケージパス内のモジュールパスを識別します。
  2. モジュールパスから派生したURLを使用して、コマンドはモジュールプロキシサーバーまたはリポジトリで直接モジュールソースを見つけます。
  3. モジュールのバージョン番号をリポジトリタグと照合してリポジトリ内のコードを検出し、ダウンロードするモジュールバージョンのソースを見つけます。使用するバージョン番号がまだ不明な場合、go getは最新のリリースバージョンを見つけます。
  4. モジュールソースを取得し、開発者のローカルモジュールキャッシュにダウンロードします。

リポジトリ内のコードの整理

ここで説明する規則に従うことで、メンテナンスを簡素化し、開発者のモジュール使用体験を向上させることができます。モジュールコードをリポジトリに取り込むことは、他のコードの場合と同様に一般的に簡単です。

次の図は、2つのパッケージを持つ単純なモジュールのソース階層を示しています。

Diagram illustrating a module source code hierarchy

最初のコミットには、次の表にリストされているファイルを含める必要があります。

ファイル説明
LICENSE モジュールのライセンス。
go.mod

モジュールパス(事実上の名前)と依存関係を含む、モジュールを記述します。詳細については、go.modリファレンスを参照してください。

モジュールパスは、次のようなモジュールディレクティブで指定されます。

module example.com/mymodule

モジュールパスの選択の詳細については、「依存関係の管理」を参照してください。

go.modファイルは編集できますが、goコマンドを使用して変更を行う方が信頼性が高くなります。

go.sum

モジュールの依存関係を表す暗号化ハッシュが含まれています。Goツールはこれらのハッシュを使用してダウンロードされたモジュールを認証し、ダウンロードされたモジュールが本物であることを確認しようとします。この確認が失敗した場合、Goはセキュリティエラーを表示します。

依存関係がない場合、ファイルは空か存在しません。go mod tidyコマンド(不要なエントリを削除します)を使用する場合を除き、このファイルは編集しないでください。

パッケージディレクトリと.goソース。 モジュール内のGoパッケージとソースを構成するディレクトリと.goファイル。

コマンドラインから、空のリポジトリを作成し、最初のコミットの一部となるファイルを追加し、メッセージ付きでコミットできます。gitを使用した例を次に示します。

$ git init
$ git add --all
$ git commit -m "mycode: initial commit"
$ git push

リポジトリスコープの選択

コードを他のモジュールのコードとは独立してバージョン管理する必要がある場合に、モジュール内のコードを公開します。

リポジトリを設計して、ルートディレクトリに単一のモジュールをホストするようにすると、特に新しいマイナーバージョンとパッチバージョンを公開し、新しいメジャーバージョンにブランチするなど、時間の経過とともにメンテナンスが簡素化されます。ただし、必要であれば、代わりに単一のリポジトリに複数のモジュールを維持することもできます。

リポジトリごとに1つのモジュールをソース化する

単一のモジュールのソースを含むリポジトリを維持できます。このモデルでは、go.modファイルをリポジトリルートに配置し、その下にGoソースを含むパッケージサブディレクトリを配置します。

これは最も簡単なアプローチであり、時間の経過とともにモジュールの管理が容易になります。モジュールバージョン番号にディレクトリパスを接頭辞として付ける必要がなくなります。

Diagram illustrating a single module's source in its repository

単一のリポジトリで複数のモジュールをソース化する

単一のリポジトリから複数のモジュールを公開できます。たとえば、単一のリポジトリに複数のモジュールを構成するコードがある場合がありますが、それらのモジュールを個別にバージョン管理したい場合があります。

モジュールルートディレクトリである各サブディレクトリには、独自のgo.modファイルが必要です。

サブディレクトリでモジュールコードをソース化すると、モジュールを公開する際に使用するバージョンタグの形式が変わります。モジュールルートであるサブディレクトリの名前をタグのバージョン番号部分の前に付ける必要があります。バージョン番号の詳細については、「モジュールのバージョン番号付け」を参照してください。

たとえば、以下のモジュールexample.com/mymodules/module1の場合、バージョンv1.2.3には次のようになります。

Diagram illustrating two modules in a single repository