Go Wiki: PackagePublishing

はじめに

何時間もかけてパッケージを記述し、デバッグし、テストした今（テストしましたよね？）、他の人があなたのパッケージをgo getできるように公開したいと思うでしょう。

まず、オンラインのどこかにホストする必要があります。主要なコードホスティングサイトは、bitbucket (hg/git)、GitHub (git)、launchpad (bzr) の3つです。使い慣れたバージョン管理システム、またはローカルマシンでコードのバージョン管理に使用しているバージョン管理システムを選択することをお勧めします。Git (git) は中央のGoリポジトリで使用されているバージョン管理システムであるため、あなたのプロジェクトを使用したい開発者が適切なソフトウェアを持っていることを保証できる最も近いものです。バージョン管理システムを一度も使用したことがない場合は、これらのウェブサイトにいくつかの素晴らしいHOWTOがあり、「{name} tutorial」（{name}は学習したいバージョン管理システムの名前）でGoogle検索することで、多くの優れたチュートリアルを見つけることができます。

パッケージのセットアップ

インポートの選択

パッケージの完全なインポートは、しばしばその作者を識別するものを含みます（特にGitHubのようなホスティングサイトでは、「github.com/kylelemons/...」が完全なインポートです）。プロジェクト名を常に含み、プロジェクト名と異なる場合は、開発したパッケージ名で終わるべきです。たとえば、go-gypsyプロジェクトはyamlパッケージを提供し、Kyle Lemonsによって書かれているため、次のインポートパスを持ちます。

import "github.com/kylelemons/go-gypsy/yaml"
             ^         ^          ^     ^
             |         |          |     `-- Package name
             |         |          `-------- Project name
             |         `------------------- Author's handle
             `----------------------------- Hosting site

Go >= バージョン1 はパッケージリポジトリのサブディレクトリをサポートします。

サブディレクトリ

多くの場合、パッケージに使用する名前には、「Go」がプレフィックス、サフィックス、または頭字語の一部として含まれることがあり、これを実際のコマンドまたはgoソースファイルのパッケージ名の一部にしたくない場合もあります。多くの場合、パッケージの一部としてライブラリとコマンドの両方を持つことがあり、これらは同じディレクトリに共存できません。これらのことが発生した場合、リポジトリをサブディレクトリで構成することになります。

たとえば、「Go-PublishingExample」というプロジェクトが「epub」パッケージと「publish」コマンドを提供しているとします。ディレクトリ構造は次のようになります。

./epub/      # Package source, all files package "epub"
./publish/   # Command source
./doc/       # Documentation which won't be downloaded
./examples/  # Example code which won't be downloaded

パッケージのインポート文は次のようになります。

import "codesite.tld/authorName/Go-PublishingExample/epub"

多くの場合、最後のディレクトリパス（この場合は「epub」）が、そのディレクトリ内のソースファイルによって使用されるパッケージ名と一致することを確認するのは良い考えです。この場合、バイナリもパッケージも「Go-PublishingExample」という名前にはならなかったため、ベースディレクトリにはgo get可能なファイルは含まれていませんでした。

ブランチとタグ

このセクションは古くなっています。以下の擬似バージョン番号はGo < バージョン1に適用されていました。また、Goリポジトリ自体は現在MercurialではなくGitを使用しています。このセクションを削除すべきかもしれません。

「go help get」と「go help importpath」を使用すると、go getに関する最新情報を取得できます。

一般的に、Goソースツリーは3つの基本的な状態に存在できます。Goリリースブランチ（この記事の執筆時点ではGoogle Codeのr60 – ほとんどのユーザーはここにいるべきです）でチェックアウトされているか、Goウィークリー（週に1回程度新しいタグが作成されます）でチェックアウトされているか、またはtip（最新の変更を意味するMercurialの用語）でチェックアウトされているかのいずれかです。最後の2つは、主にGo言語自体の開発者、または最新のリリースには導入されていない機能や修正を必要とする開発者向けです。

一般公開には適さないコードでチームとプロジェクトでの共同作業を続ける可能性が高いため、バージョン管理システムのタグ付けまたはブランチ機能を利用することをお勧めします。go getツールは、ユーザーが互換性のあるバージョンのパッケージを取得できるようにするために使用したい、いくつかの特別なタグとブランチを理解しています。

  go.r60               -- A "go.r##" tag will be checked out if the user has that Go release installed
  go.weekly.2011-07-19 -- A "go.weekly.YYYY-MM-DD" tag will be checked out if the user has that weekly installed

go getは、インストールされたものに一致するものがない場合、以前のタグにフォールバックしようとし、何も見つからない場合は、デフォルトでtipをインストールします。

Mercurialでリリース​​タグを作成および維持するには

## Create or update a release tag
hg tag myProj-v0.0 # tag an easy-to-remember version number if you wish
hg tag go.r60 # tag this as being go release.r60 compatible

Gitでリリース​​ブランチを作成および維持するには

## Create a release branch
git tag myProj-v0.0     # Tag an easy-to-remember version number if you wish
git checkout -b go.r60  # create a release branch
git checkout master     # to switch back to your master branch

## Update the release branch
git checkout go.r60  # switch to the release branch
git merge master     # merge in changes from the master branch since last release
git checkout master  # switch back to master branch

他のブランチ名を使用している場合は、必要に応じてそれらの名前を置き換えてください。

通常、毎週のタグやブランチを維持する必要はありませんが、リリースブランチやタグを維持することは非常に役立ちます。これにより、プロジェクトの視聴者層が最も広くなります。

コマンドとパッケージ

go getはプロジェクトのMakefileを使用しないため、実際にプロジェクトをどのようにビルドするかを理解することが重要です。

同じディレクトリ内のすべてのファイルは、常に同じパッケージ名を共有する必要があります。_testまたは_osおよび/または_archサフィックスで命名されたファイルは（os/archが一致しない限り）無視されます。パッケージ名が「main」の場合、go getはソースファイルから実行可能ファイルをビルドし、ディレクトリ名（最後のパスセグメントのみを使用）に従って命名します。パッケージ名がそれ以外の場合、go getはそれをパッケージとしてビルドし、インポートパスはプロジェクトのルートのWebアクセス可能なURLとサブディレクトリになります。主要な4つ以外のコードホスティングサイトのインポートパスを作成する方法については、go getのドキュメントを参照してください。

同じプロジェクト内のパッケージ間の依存関係は一般的です。プロジェクト内の1つのパッケージまたはコマンドが別のパッケージに依存している場合、go getが依存関係を認識してビルドを確実にするために、完全なインポートパスを使用する必要があります。プロジェクトのソースファイルからインポートされるサードパーティのパッケージも、まだ存在しない場合はgo getによって自動的にダウンロードおよびインストールされます。

上記の例を再利用すると、ファイル./publish/main.goは次のようになります。

package main

import (
    "flag"
)

import "codesite.tld/authorName/Go-PublishingExample/epub"

var dir = flag.String("dir", ".", "Directory to publish")

func main() {
    flag.Parse()
    epub.Publish(*dir)
}

この実行可能ファイルをインストールしたいユーザーは次を実行します。

go get codesite.tld/authorName/Go-PublishingExample/publish

これにより、依存関係のために".../epub"パッケージもインストールされます。単にライブラリをインストールしたい開発者は次を実行できます。

go get codesite.tld/authorName/Go-PublishingExample/epub

そして（publishをまだインストールしていなかった場合）、パッケージのみがダウンロードおよびインストールされます。これらのどの場合でも、例やドキュメントはダウンロードされないことに注意してください。ほとんどの場合、これらはコードサイトを通じて参照できます。

ドキュメント

godoc

パッケージを公開する準備をしているときは、godocのローカルコピーを実行して、ドキュメントが正しく表示されていることを確認する必要があります。パッケージがgoパッケージツリーにインストールされている場合は、次のコマンドを使用できます。

  godoc -http=:6060 &

その後、https://:6060/pkg/ にアクセスしてパッケージを見つけます。

ダッシュボード

Goダッシュボードは、パッケージレベルのコメントの最初の行（通常のgodoc形式も使用）を「情報」テキストとして使用するため、これが設定されていることを確認してください。例：

// Package epub is an example publishing library.
package epub

godocの詳細については、Goコードのドキュメント化のブログ記事を参照してください。

このコンテンツはGo Wikiの一部です。

go.dev は、サービスの品質を提供および向上させ、トラフィックを分析するために、Google の Cookie を使用しています。詳細はこちらをご覧ください。