kako-junです
好きな高橋は 高橋和希です
cdandをリリースしました
READMEの翻訳が大変だった
日本語も、英語も
Goは初体験だったし
Goの常識から勉強し始めて
4つのツールを並行して作ってたので
1ヶ月くらい掛かったわ
半分が READMEをKAWAII感じに書く時間
迷った点と結論
CLIツール用のパッケージとして
- flag
- urfave/cli
- spf13/cobra
のどれを使うか？
flagを選んだよ
基礎は大事
ビルド済みのバイナリを作るか 作らないか
作ることにしたー
それをリポジトリに含めてるプロジェクトって あんま見ないけど
大したサイズでもないし
Raspberry Pi用のバイナリとか ビルド済みだったら興味持つやん
アイコンの埋め込み方
.ico を .syso 形式に変換して
mainパッケージの .go と同じ場所に置いて
引数に .go ファイルを指定せず go build することで
ディレクトリ名のバイナリが作られるやり方を選んだ
けど アイコンが変わったのはWindows用exeのみ
バージョン情報の埋め込み方
Goだと実現方法がユーザーの自由とは……！
多くの例では コミットのハッシュ、時刻とかも埋め込んでたけど
要らないなぁ……
バージョン番号も
go build に引数で与えるやり方が多くて
いやー
.go ファイルに直書きすべきやろー
と思って、そーした
Goのパッケージ名の制約
ハイフンもアンダーバーもダメ
それで cd-and から cdand に
途中で変わった
mainパッケージに 全部書くのはやなので
コアなロジック部分をクラスにして
別の .go に取り出したんよ
それの import 方法がややこしくて
分かるまで実験しまくった
1度分かると簡単なせいか
ググっても 法則を説明してる例が少ないんよ
具体的には
リポジトリのルートに cdand.go を置いたとする
コアなロジック部分を取り出したファイルを cdand-core.go とする
2つは同じディレクトリに置けない
.go ファイルは
1ディレクトリに1つ
cdand.go は
CLIとしてのエントリポイント
mainパッケージを担当
引数のチェックをした後で
cdand-core.go のpublicな関数
を1つ呼ぶだけ
cdand-core.go には
CdAnd というクラスが1つあるだけ
パッケージ名は cdand
ここは cdand-core という名前でもイイ気がするやん？
そのへんの決め方がややこしかった
ただ 選択肢はたくさんあるけど 自動的に決まってく
まず
最終的なコマンド名を cdand にしたいワケで
それは go build を実行するディレクトリ名で決まる
リポジトリのルートに
cdand とゆーディレクトリを作って
そこでビルドしてもイイんだけど
そーする理由もないので
リポジトリ名が cdand に決まるわ
cdand とゆーディレクトリに
cdand.go があって
そのパッケージ名が main
その下にサブディレクリを作って
cdand-core.go を置くワケだけど
同じ命名規則から行くと
サブディレクトリ名は cdand-core に決まる
けど
パッケージ名は cdand-core に決まらない
まだ cdand とゆーパッケージ名が未使用だし
とゆーか 2単語以上だとパッケージ名に使えなかった
あと
import の指定方法が
- GOPATH外で作り始めた場合と
- しっかりGOPATH内で作り始めた場合や、
go getで取ってきた場合
とで、違うとゆーのが 最初分かんなかった
cdand.go の序盤に
cdand-core.go を import する1行が必要で
それのこと
GOPATH外で開発するだけなら
import "./cdand-core"
って書けば、読み込んでくれるんよ
（import "cdand-core" じゃダメ）
ただ、それだと
GitHubにpushして
誰でも go get で使えるよーにしたいなー
って思った時、うまく行かないんよ
その場合は
import "github.com/kako-jun/cdand/cdand-core"
みたいに
GOPATH内でのディレクトリ階層を 書いてあげないと怒られるんよ
go get の時は
go get github.com/kako-jun/cdand
止まりなんよ
でも
import の時は
import "github.com/kako-jun/cdand"
でなく
import "github.com/kako-jun/cdand/cdand-core"
まで必要なんよ
欲しいのは mainパッケージじゃないから
そして
import "github.com/kako-jun/cdand/cdand-core"
の意味は
GOPATHの src/github.com/kako-jun/cdand/cdand-core
にある .go ファイルを読み込め
だから
動的にGitHub.comから 取得してくれるワケではないし
GOPATH外で開発してる場合は
go get -u github.com/kako-jun/cdand
しとかないと
最新の cdand-core.go を読み込んでくれないんよ
フツーは 素直にGOPATH内で開発するんだろーけど
私のC101PAは 本体の空きが1GBくらいなので
~/go/src でなく
SDカードにリポジトリを置いてるんよ
そのせいで ハマったわー
最後に こーやって作ったGo製ツールのリポジトリを
GitHubに公開する時
どう公開するか？
-
ソースだけ公開して、いじりたい人は
git cloneすればイイ と決めるか -
CLIツールとして使いやすいように 各OS用のビルド済み実行ファイルを配布したいのか
-
せっかくGoで作ったんだし
go getに対応させたいか
もし go get に対応させることができれば
Goの開発環境を入れてる人ならば
git clone 無しでソースを取得できるし
getついでに自動的にビルドされて ~/go/bin に入る
たいていはPATHを通してるだろーから
go get した直後に
cdand コマンドが使えるようになる
go get はもう古いとか
dep に対応させよう
って書いてる人もいた
ただ 私には
dep の結果作られた
vendor ディレクトリ（他人のコード）を
自分のコードと一緒にコミットする とゆーのが
感覚的にNGな気がしたの
1, 2, 3 の目的別に リポジトリを3つ公開するのもアリだけど
1つのリポジトリで全部実現できるのが 今回選んだディレクトリ構成なんよ
残り3つのツールも この構成で作るわ