Go独自の環境変数

Goに閉じた環境変数がいくつかある。
これらはgoコマンドの実行にあたって参照されており、意識しておく必要がある。

Go独自の環境変数の確認

# goに閉じた環境変数とその値の一覧表示
go env

# 特定の環境変数の値を変更
go env -w <環境変数>=<値>

※シェルの環境変数 と goに閉じた環境変数 がかぶる場合はシェル側が優先される

GOBIN

go installでインストールしたコマンドの格納先になる。

# 確認 
go env | grep GOBIN
=>
GOBIN="<パス>"

# 設定
go env -w GOBIN="<パス>"

なお、環境変数「GOBIN」が未設定の場合、go installでインストールしたコマンドの格納先は、$GOPATH/binになる。

GOMODCACHE

go mod tidyでインストールした依存先モジュールの格納先になる。
※デフォルト値は$GOPATH/pkg/mod

# 確認
go env | grep GOMODCACHE
=>
GOMODCACHE="xxxxxxxxx"

# 設定
go env -w GOMODCACHE="<パス>"

# 削除(モジュールキャッシュのクリア)
go clean -modcache
=>「GOMODCACHE」のディレクトリごと削除される。

GOOS, GOARCH

実行ファイルをビルドするときに使われるOSとアーキテクチャの設定。

Goのコマンド

インストール系コマンド

以下2つを使い分ける。用途は全然違う。

• go install: Goで開発されたコマンドラインツールのインストール
• go mod tidy: カレントモジュールの依存先モジュールのインストール & 不要なモジュールの削除
  go getというコマンドもあるが、現バージョンではいらない子なので気にしなくてよい。

go install

# リポジトリで公開されているGoプロジェクト(モジュール)の場合
go install github.com/<オーナー>/<モジュール名>@<バージョン>

# ローカルのGoプロジェクトの場合
go install < main()を含む.goが配置されているローカルディレクトリのパス > 

主な用途は、 Goで開発されたコマンドラインツールのインストール。
指定した「mainパッケージを含むGoプロジェクト」をビルドして、バイナリを$GOBINへ配置するという挙動になる。
対象にmainパッケージが存在しない場合、エラーになる。
<バージョン>に、latestを指定すると最新バージョンでインストールされる。

go mod tidy

モジュール, go.mod, go.sumが前提知識として必要になる。
こちらを参照。

用途は、カレントモジュール(go.modが存在するディレクトリ配下。≒自身が開発中のモジュール)に必要になる外部パッケージのモジュールのインストールおよび、不要になったものの削除。
goでの開発時には、各.goファイルにおいて、必要になる自身以外のパッケージをimportディレクティブに記述する(下のような形)。

package main

import (
  "fmt"
  "github.com/aws/aws-sdk-go-v2/aws"
)

func main (){
  ...
}

この記述をした上で、go mod tidyを実行すると、importディレクティブには記述されているが、まだローカルにはインストールしていないパッケージのモジュール(+それらが依存するモジュール)をインストールしてくれつつ、go.mod, go.sumを更新してくれる。
インストール先は、こちらを参照

なお、importディレクティブから不要になった外部パッケージを削除してgo mod tidyを実行すると、そのモジュールはローカルから削除される。こちらについてもgo.mod, go.sumを更新してくれる。
-vオプションをつけて実行すると、削除されたモジュールが``unused <パッケージ名>`という形で出力される。

ビルド・実行系コマンド

go test xxx_test.go|[前提]xxx_test.goは、テストソース・ファイル。
xxx_test.go内にかかれているテスト関数が実行される。

go build

go build <エントリポイントを含む.goファイルへのパス>

• goのエントリポイントは、mainパッケージのmain()関数。
• コマンドを実行すると実行ファイルが作られる
• 実行ファイルは./<実行ファイル>で実行できる
  • ※実行ファイルの形式は、環境変数GOOS, GOARCHの組み合わせによって変わる
    • Intel Macだと GOOS: darwin, GOARCH: amd64。
    • GOOS, GOARCH の可能な組み合わせはこちらを参照。

go run

go run <エントリポイントを含む.goファイルへのパス>

• goのエントリポイントは、mainパッケージのmain()関数。
• ビルドして実行ファイルを作成し、その実行までも一貫して行ってくれる。
  • 実行ファイルは一時的なもので、実行後に自動で削除される。
  • -workを付けると、実行ファイルは削除されず、作成先のパスを出力してくれる(が、だったら素直にgo buildすればいいのではと思う)
• パスはファイル名まで指定しても、ファイルがあるディレクトリまででも実行できる模様。

go test

以下のように実行することが多いかと思う

go test -v -run <実行したいテスト関数名の正規表現> <xxx_test.goを配下に含むディレクトリへのパス>/...

-v: つけないと実行したテストの中で失敗したものだけログ出力されるが、つけると成功したテストも出力してくれる。
-run <実行したいテスト関数名の正規表現>: つけないと全テスト関数を実行。
<ディレクトリへのパス>/...: そのディレクトリ配下のテストを再帰的に実行してくれる。

確認系コマンド

go list

依存パッケージを調べるのに使う。

Goコマンドのヘルプを和訳してみた

go mod init

go help mod initコマンドによると、以下のような説明が書かれている。

「init」コマンドは、初期化して、カレントディレクトリに新しい「go.mod」ファイルを作り、
実質的に「カレントディレクトリをルートディレクトリとする新しいモジュール」を生成する。

「go.mod」ファイルがすでに存在している場合は実行できない。

「init」コマンドは、「新しいモジュールのモジュールパス」を引数に取ることができる。
モジュールパスの引数が省略された場合は、
「.goファイル内のimportコメント」
「Gopkg.lockのような外部パッケージツールの設定ファイル」
「カレントディレクトリ(GOPATH内ならば)」
を使ってモジュールパスの推測を試みる。

外部パッケージツールの設定ファイルが存在する場合、「init」は設定ファイルからモジュールの必要物をインポートする。

「go mod init」についてもっと知りたいならば https://golang.org/ref/mod#go-mod-init を参照。

go mod tidy

go help mod tidyコマンドによると、以下のような説明が書かれている。

使い方: go mod tidy [-e] [-v] [-go=version] [-compat=version]

Tidyコマンドは、「go.modがそのモジュール内のソースコードとマッチしているか」をチェックする。
Tidyコマンドは、現在のモジュールのパッケージや依存関係をビルドするために必要だが、見つからないモジュールを追加し、
関連するパッケージを供給しない使われていないモジュールを削除する。
Tidyコマンドは、go.sumに必要な記述を追加し、不要な記述を削除する。

「-v」は、削除されたモジュールの情報を標準エラー出力へ表示するようになる。
「-e」は、パッケージ読み込み中に遭遇したエラーをよそに、続行しようとする。
「-go」はgo.modファイル内の「go」の記述を与えたバージョンで更新し、
どのモジュールの依存関係が「go.mod」ファイル内の明示的な要件として維持されるかを変更するかもしれない。


(Goバージョン1.17以上だと、モジュールの遅延読み込みをサポートするためのより多くの要件が維持される)

「-compat」は「go」コマンドが、うまくモジュールのグラフを読み込むためのメジャーバージョンのGoのリリースを示す、追加のチェックサムを保存する
「go」コマンドのバージョンとは異なるモジュールのバージョンからインポートされたパッケージを読み込みそうならば、エラーを出力する。
デフォルトでは、「Tidy」コマンドは
「go.mod」ファイル内の「go」の記述によって示されるより前のバージョンとしてふるまう

「go mod tidy」についてもっと知りたいならば https://golang.org/ref/mod#go-mod-tidy を参照。

参考

環境変数

コマンド