Golang

install

最低限GOPATHの設定は必要

golang 1.11以降ならgomodule使ったほうが自由

code:profile

export GO111MODULE=on

export GOPATH="$HOME/go"

export PATH=$PATH:$GOPATH/bin

何もかも忘れてたので0からいろいろ

WSLでの開発

GOPATHについて

go get 等で取得したバイナリ、ソースコードはGOPATH環境変数の先のpkg,srcに置かれている。

code:dir structure

├─bin

├─pkg

└── src

golang.org

├─ github.com

├─ tanisobe/project

project direcotry structure

自分が実際に管理するproject以下のdirecotry structureについては

色々な流派やシステムアーキテクチャによるものがあるので一般解はないっぽい。

そもそも小さな個人プロジェクトレベルならベタにmain.goをポンと置く程度でいい説もある。

普通の個人レベルの開発だとpkgディレクトリはいらないかも。internalは外部のimportパッケージ、関数名がかぶった場合にinternel下に配置したパッケージは別物として利用できる仕組みらしい。あまりないとは思うが、一応覚えておく。

code:dir structure

├─ cmd 実際に実行するコマンドを配置するのによさげ。main.goとかのエントリーポイントを各イメージ

|　 ├─ cmdA/main.go

| ├─ cmdB/main.go

├─ pkg 外部プロジェクトで再利用可能なpkgはここにおくらしい

├─ web serversideのtemplateやjs等のassetをおくっぽい。

├─ init systemdやupstart等のコンフィグはここにおくっぽい

├─ deployments docker-composeとかansibleとかここにおくっぽい。

├─ config いわゆる設定ファイルとか

├─ scripts 雑多なスクリプトをおく。

├─ vendor go1.11くらいまで使っていたがgo moduleの登場でたぶん使わないvendoring用のdir

go get

golang template Actions

memo

golang1.11.5で次の問題にぶち当たって、いくつかのツールがgo getできなかった。go1.12にしたところ改善した。

gomodule

go1.11で導入された仕組み。

関連するパッケージはすべてGOPATH配下のローカルに落とすフローだった

基本がgithubの最新版のパッケージを使う思想

個別パッケージのバージョン管理ができない欠点

特定バージョンのパッケージを使う場合は別directoryに特定バージョンのパッケージをコピーしていた

gomoduleでパッケージの個別バージョン管理が簡単にできるようになった。

GOPATH配下以外にmoduleは落とされるのでGOPATH依存がなくなった。

Private module

goのmodule管理はインターネット上のmodule proxyやversion contorlに依存している

github enterpriseではinternet上のそういったリソースを利用できないことがほとんどなので何かしら対応が必要

go env -w GOPRIVATE=ghe.example.com

go.modには各パッケージのバージョン含めた依存関係が記述

go.sumが作成される。

go.sumはビルド環境のモジュール状態が適正か確認するハッシュをまとめたチェックサムファイル

go.sumはgit管理したほうが良いとのこと

code:=gomodule利用の流れ

# go1.13移行はdefault on

export GO111MODULE=on

# go.mod生成

go mod init github.com/my/repo

go mod tidy