コマンド＠Go

はじめに

本サイトにつきまして、以下をご認識のほど宜しくお願いいたします。

• https://hiroki-it.github.io/tech-notebook/

01. goコマンド

build

▼ buildとは

指定したパスをビルド対象として、ビルドのアーティファクトを作成する。

foo_test.goファイルはビルドから自動的に除外される。

アーティファクトの出力先を指定しない場合に、

# cmdディレクトリをビルド対象として、ルートディレクトリにcmdアーティファクトを作成する。
$ go build ./cmd

もし、ビルドのエラー時に終了ステータスのみが返却され、原因が不明の場合、panic関数が原因を握りつぶしている可能性を考える。

exit status 2. Docker build ran into internal error. Please retry. If this keeps happening, please open an issue..

▼ -o

指定したパスにビルドのアーティファクトを作成する。

ビルド対象パスを指定しない場合、ルートディレクトリのgoファイルをビルドの対象とする。

# ルートディレクトリ内のgoファイルをビルド対象として
# $HOME/go/binディレクトリにルートディレクトリ名アーティファクトを作成する。
$ go build -o $HOME/go/bin

また、指定したパス内のgoファイルをビルド対象として、指定したパスにビルドのアーティファクトを作成もできる。

# cmdディレクトリ内のgoファイルをビルド対象として
# $HOME/go/binディレクトリにcmdアーティファクトを作成する。
$ go build -o $HOME/go/bin ./cmd

補足として、事前のインストールに失敗に、ビルド対象が存在していないと以下のようなエラーになってしまう。

package foo is not in GOROOT (/usr/local/go/src/foo)

clean

モジュールのキャッシュを削除する。

ローカル環境での開発中にgo installコマンドを実行しても、モジュールをアップグレードできない場合に使用する。

$ go clean --modcache

$ go mod tidy

env

▼ envとは

Goに関する環境変数を出力する。

＊実装例＊

$ go env

GO111MODULE="on"
GOARCH="amd64"

...

PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build887404645=/tmp/go-build -gno-record-gcc-switches"

fmt

▼ fmtとは

指定したパスのファイルのインデントを整形する。

パスとして『./...』を指定して、再帰的に実行するのがおすすめ。

$ go fmt ./...

install

▼ installとは

go getコマンドとは異なり、Goのバイナリをモジュールとしてでなく、ツールとしてグローバルにインストールする。

コードと外部モジュールに対してbuildコマンドを実行することにより、$GOPATH以下のbinディレクトリまたはpkgディレクトリにインストール (配置) する。

内部または外部のコードからビルドされたアーティファクト (バイナリファイル) であればbinディレクトリ配下に配置し、それ以外 (例：.aファイル) であればpkgディレクトリ配下に配置する。

# asdfでGoをインストールしている場合は、go installコマンドの前に`PATH`を設定しておく
$ export PATH="$(go env GOPATH)/bin:$PATH"

$ go install

なお、インストールしたモジュールでreplaceを使用している場合、クローンしてから直接インストールする必要がある。

$ git clone <モジュールのリポジトリ>
$ cd <バイナリのディレクトリ>
$ go install

バイナリは、パスが通っていないため、直接パスを指定して実行する必要がある。

$ ${GOPATH}/bin/foo-package --version

• https://go.dev/doc/go-get-install-deprecation
• https://github.com/golang/go/issues/44840#issuecomment-1828537390
• https://okkun-sh.hatenablog.com/entry/2023/06/16/013008

▼ 最新バージョンの指定

HEADを指定すると、最新のコミットIDを指定できる。

複数のブランチがある場合は、時系列的に最新のコミットIDである。

$ go install <モジュール名>@HEAD

• https://zenn.dev/podhmo/articles/f7d6b5ccc389b5ecef02

▼ バイナリのアンインストール

go installコマンドでインストールしたバイナリは、rmコマンドで直接削除する必要がある。

$ ls ${GOPATH}/bin

foo-package

$ rm ${GOPATH}/bin/foo-package

• https://www.reddit.com/r/golang/comments/zfly1c/comment/izck1cl/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

run

▼ runとは

go buildコマンドを実行しつつ、バイナリを実行する。

ソースコードを変更した後に動作を簡易的に確認する場合に便利である。

ただ、logモジュールなど処理中のメッセージは表示されず、main.goファイルの実行結果しかわからないため、エラーのデバッグには使いにくい。

$ go run ./...

test

▼ testとは

指定したパスのfoo_test.goファイルで『Test』から始まるテスト関数を実行する。

testディレクトリ内を再帰的に実行するのがおすすめ。

$ go test ./...

▼ -v

テスト時にテストの実施時間を出力する。

$ go test -v ./...

▼ -cover

テスト時に、foo_test.goファイルがあるモジュール内ファイルの命令網羅の網羅率を解析する。

反対に、foo_test.goファイルがなければ、そのモジュールの網羅率は解析しない。

$ go test -cover ./...

▼ -coverpkg

モジュールを指定して、網羅率を解析する。

デフォルトではテストコードがあるモジュールしか解析しないため、全てのモジュールを含めて解析するために./...を指定する。

$ go test -coverpkg=./... -coverprofile=coverage.txt ./...

• https://www.getto.systems/entry/2020/08/09/190650

▼ -coverprofile

網羅率を解析し、結果からカバレッジレポートを作成する。

$ go test -coverprofile=coverage.txt ./...

• https://kiririmode.hatenablog.jp/entry/20210204/1612450799

tool

▼ cover

カバレッジレポートを使用して、特定のコンポーネントでのカバレッジを算出する。

モジュール単位、関数単位 (-func) 、全体、のカバレッジを指定できる。

$ go tool cover -func coverage.txt

• https://gihyo.jp/article/2023/03/tukinami-go-05

version

▼ -m

バイナリで使用しているGoのバージョンと、モジュールのバージョンを出力する。

$ go version -m <Goのバイナリのパス>

<Goのバイナリのパス>: go 1.19.5
...

• https://knqyf263.hatenablog.com/entry/2021/02/12/162928

vet

▼ vetとは

指定したパスのファイルに対して、静的解析を実施する。

パスとして『./...』を指定して、再帰的に実行するのがおすすめ。

$ go vet ./...

02. モジュール管理系

大前提

Goでは、思想的にモジュールのバージョンを固定して運用せず、常に新しいバージョンを強制的に利用させるような仕組みがある。

get

▼ getとは

指定したパスからモジュールをダウンロードし、これに対してinstallコマンドを実行する。

また、go.modファイルも更新する。

これにより、内部または外部のコードからビルドされたアーティファクト (バイナリファイル) であればbinディレクトリ配下に配置し、それ以外 (例：.aファイル) であればpkgディレクトリ配下に配置する。

go getコマンドは不用意にgo.modファイル上の他のモジュールの定義も更新してしまうため、非推奨である。

# インストールの場合
$ go get <ドメインをルートとしたURL>@<バージョン>

go: downloading <ドメインをルートとしたURL> <バージョン>
go: added <ドメインをルートとしたURL> <バージョン>

# アップグレードの場合
$ go get <ドメインをルートとしたURL>@<バージョン>

go: downloading <ドメインをルートとしたURL> <バージョン>
go: upgraded <ドメインをルートとしたURL> <バージョン>

• https://go.dev/doc/go-get-install-deprecation
• https://qiita.com/eihigh/items/9fe52804610a8c4b7e41

▼ go mod tidyとの使い分け

先にインストールしたモジュールのバージョンが優先になり、このバージョンを基準として他のモジュールのバージョンが決まる。

そのため、開発者によって結果が変わってしまう。

その反面、go mod tidyコマンドは同じ結果になる。

もし全てのモジュールのバージョンを開発者に限らず揃えたいなら、go mod tidyコマンドを使用する。

• https://blog.lufia.org/entry/2020/02/24/171513

mod edit

▼ mod editとは

go.modファイルで指定しているバージョンを変更する。

$ go mod edit

mod tidy

▼ mod tidyとは

• importで指定されているがgo getコマンドでインストールされていない場合は、これをインストールする。
• importで指定のないモジュールは、go.modファイルとgo.sumファイルから削除する。
• importで指定されているがgo.modファイルとgo.sumファイルに定義がない場合は、これを追加する。
• アップグレード可能なモジュールはバージョンを変更する。

$ go mod tidy

もしgo.sumファイルにモジュールの指定があるのにも関わらず、以下のようなエラー (missing go.sum entry) が出る時は、go mod tidyコマンドを実行してgo.sumファイルを更新する必要がある。

cmd/main.go:4:5: missing go.sum entry for module providing package github.com/foo/foo-package (imported by github.com/hiroki-it/bar/cmd); to add:
        go get github.com/hiroki-hasegawa/bar/cmd

• https://go.dev/ref/mod#go-mod-tidy
• https://zenn.dev/optimisuke/articles/105feac3f8e726830f8c#go-mod-tidy
• https://blog.framinal.life/entry/2021/04/11/013819#go-mod-tidy

▼ -go

go.modファイルに記載のGoのバージョンを上書きしつつ、go.sumファイルを更新する。

ただし、-goオプションは推奨バージョンを設定できるだけで、これを守らない場合もある。

$ go mod tidy -go <バージョン>

• https://zenn.dev/spiegel/articles/20210223-go-module-aware-mode#go-%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%86%E3%82%A3%E3%83%96%E3%82%92%E6%9B%B4%E6%96%B0%E3%81%99%E3%82%8B

▼ -v

importしていないためにgo.modファイルから削除したモジュールを、標準出力に出力する。

$ go mod tidy -v

unused <go.modファイルから削除したモジュール>

• https://developer.so-tech.co.jp/entry/2022/08/16/110108

▼ go getとの使い分け

go mod tidyコマンドは、たとえ-goオプションを使用しても、インストールするモジュールのバージョンを完全には制御できない。

(Goの思想的にも) できるだけ新しいバージョンを強制しようとするため、想定するバージョンよりも新しいモジュールをインストールしてしまう可能性がある。

そのため、特定のバージョン (特にコミットIDでの指定) はgo getコマンドでインストールする必要がある。

ただ推奨としては、Goの思想に則り、go mod tidyコマンドを実行して常に新しいバージョンを使用する方が良い。

• https://blog.lufia.org/entry/2020/02/24/171513

mod verify

▼ mod verifyとは

go.sumファイルが正しいかどうかを検証する。

$ go mod verify

all modules verified

• https://go.dev/ref/mod#go-mod-verify

▼ but does not contain package

インポートしたモジュールの依存先モジュールをダウンロードしたが、依存先モジュール内にモジュールがないことを表す。

// indiretで自動的に指定しているモジュールが新すぎる可能性がある。

この場合、// indiretのモジュールを手動で変更する。

＊例＊

// indiretで指定した依存先モジュール (go.module.io/foo-dependency) のバージョンが1.27になっている。

しかし、go.module.io/foo-dependency (1.27) には、barモジュールがないためエラーになっている。

この場合、barモジュールがあるバージョンに手動で書き換える必要がある。

$ go mod verify

go: finding module for package go.module.io/foo-dependency
        github.com/foo imports
        go.module.io/foo-dependency/bar: module go.module.io/foo-dependency@latest found (v1.27.0), but does not contain package go.module.io/foo-dependency/bar

• https://budougumi0617.github.io/2019/09/20/fix-go-mod-tidy-does-not-contain-package/

mod download

▼ mod downloadとは

• importで指定されているがgo getコマンドでインストールされていない場合は、これをインストールする。
• importで指定されているがgo.modファイルとgo.sumファイルに定義がない場合は、これを追加する。

• https://go.dev/ref/mod#go-mod-download
• https://github.com/golang/go/issues/35832#issuecomment-571799739

go.modファイル

▼ go.modファイルとは

アプリケーションで必要なモジュールのバージョンを設定する。

モジュール内にgo.modファイルがある場合、そこに記載のあるバージョンは最低限必要なバージョンになる。

基本的には、モジュールのURLやディレクトリ構成と同じにする。

module github.com/hiroki-hasegawa/foo-repository

go 1.16

▼ パブリックリポジトリから (リリース済み)

モジュール名とバージョンタグを使用して、パブリックリポジトリからリリース済みのモジュールをインポートする。

go mod tidyコマンドによって// indirectコメントのついたモジュールが実装される。

これは、インポートしたモジュールではなく、インポートしているモジュールが依存しているモジュールである。

注意点として、モジュール名は、使用したいモジュールのgo.modファイルを参照すること。

module github.com/hiroki-hasegawa/foo-repository

go 1.16

// 直接的に依存するモジュール (アプリで使用するモジュール)
require (
    <モジュール名> <バージョンタグ>
    github.com/foo v1.3.0
    github.com/bar v1.0.0
)

// 間接的に依存するモジュール (アプリで使用するモジュールが依存するモジュール)
require (
    github.com/baz v1.0.0 // indirect
)

import "github.com/bar"

func main() {
    // 何らかの処理
}

• https://github.com/golang/go/wiki/Modules#should-i-commit-my-gosum-file-as-well-as-my-gomod-file
• https://developer.so-tech.co.jp/entry/2022/08/16/110108

▼ パブリックリポジトリから (開発中)

コミットIDやバージョンタグを使用して、パブリックリポジトリから開発中のモジュールをインポートする。

この場合、go getコマンドで特定のコミットIDやバージョンタグを指定し、モジュールをインストールする。

$ go get github.com/foo@<コミットID>

go: downloading github.com/foo v0.0.0-<コミット日時のタイムスタンプ>-<コミットID>
go: added github.com/foo v0.0.0-<コミット日時のタイムスタンプ>-<コミットID>

go getコマンドは、go.modファイルにインポート定義を追加する。

module github.com/hiroki-hasegawa/foo-repository

go 1.16

require (
    github.com/foo v0.0.0-<コミット日時のタイムスタンプ>-<コミットID> // indirect
)

• https://stackoverflow.com/a/53682399

▼ プライベートリポジトリから

デフォルトでは、プライベートリポジトリのモジュールをインポートできない。

$ go get github.com/foo@<コミットID/バージョンタグ>

github.com/foo@v1.0.0: verifying module: github.com/foo@v1.0.0: reading https://sum.golang.org/lookup/github.com/foo@v1.0.0: 410 Gone
    server response:
    not found: github.com/foo@v1.0.0: invalid version: git ls-remote -q origin in /tmp/gopath/pkg/mod/cache/vcs/*****: exit status 128:
        fatal: unable to look up github.com/foo.git (port 9418) (Name or service not known)

GOPRIVATE変数にプライベートリポジトリのURLを設定することで、インポートできるようになる。

$ go env -w GOPRIVATE=github.com/foo.git,github.com/bar.git,...

• https://goproxy.io/docs/GOPRIVATE-env.html
• https://kawaken.dev/posts/20220426_goprivate/

▼ ローカルマシンから

ローカルマシンのみで使用する自前共有モジュールがあるとする。

foo-repository/
├── cmd/
│   └── hello.go
│
├── go.mod
├── go.sum
└── local-pkg/
    ├── go.mod # 各モジュールにgo.modを配置する。
    └── module.go

// go.modファイル
module github.com/hiroki-hasegawa/foo-repository/local-pkg

go 1.16

この場合、パブリックリポジトリ上での自身のリポジトリからインポートせずに、replace関数を使用してインポートする必要がある。

自前共有の全モジュールでモジュール名を置換する必要はなく、プロジェクトのルートパスについてのみ定義すれば良い。

パス実際、unknown revisionのエラーで、バージョンを見つけられない。

• https://qiita.com/hnishi/items/a9217249d7832ed2c035

module github.com/hiroki-hasegawa/foo-repository

go 1.16

replace github.com/hiroki-hasegawa/foo-repository/local-pkg => /

これらにより、ローカルマシンのモジュールをインポートできるようになる。

package main

import "local.packages/local-pkg"

func main() {
    // 何らかの処理
}

go.sumファイル

▼ go.sumファイルとは

PHPにおけるcomposer.lockファイルに相当する。

go.modファイルによって実際にインストールされたモジュールが自動的に実装される。

モジュールごとのチェックサムが記録されるため、前回のインストール時と比較して、モジュールに変更があるか否かを検知できる。