モジュールソースの管理

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

このトピックでは、モジュールリポジトリを管理する際に行う可能性のあるアクションについて説明します。バージョンからバージョンへの改訂を行う際のワークフローの手順については、モジュールのリリースとバージョン管理ワークフローを参照してください。

ここで説明する規則の中には、モジュールで必須のものもあれば、ベストプラクティスであるものもあります。このコンテンツは、依存関係の管理で説明されている基本的なモジュールの使用方法に精通していることを前提としています。

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には次のようになります。

  • モジュールパス: example.com/mymodules/module1
  • バージョンタグ: module1/v1.2.3
  • ユーザーがインポートするパッケージパス: example.com/mymodules/module1/package1
  • ユーザーのrequireディレクティブで指定されたモジュールパスとバージョン: example.com/mymodules/module1 v1.2.3

Diagram illustrating two modules in a single repository