menu
書いてる野郎
orebike@gmail.com
ver 1.8 以降?の標準的パッケージ管理ツール
・・・だと思うが 2018年08月現在、もうオワコンで、dep というツールに移行が推奨されているらしい・・・こういうベース部分で錯綜するのってよくないと思うんだが。
dep は Golang オフィシャルのツールっぽいので、おそらくこいつが決定版になるようだ。 なりませんでした。
$ brew install glide $ glide --version glide version 0.13.0
まず大前提として、 Go では自分が作る全てのプロジェクトは必ず $GOPATH/src
配下に無いといけないということになっている。
他の言語のように何処にでも配置していいわけでは無い。
初期の Go ではパッケージ管理は標準であったのだが、バージョン管理はできず、そして全部グローバルにインストールされるという仕様だった。 そこでプロジェクト個々のディレクトリにインストールして使えるようになったという機能が vendoring というもの。
この Glide というツールは Go のパッケージ管理にバージョン指定の機能を加えたモノで、上記の vendoring と組み合わせることで、 他の言語のパッケージ管理ツールと同等の機能を実現するというモノである。
話は戻ってソースの配置位置の問題だが、この $GOPATH/src
というのは本来なら go get
によって取得された外部のパッケージが保存される場所であった。Java の Maven で言うならば .m2
みたいなディレクトリだったわけだ。
つまり、そこにソースを置けということは「お前らのソースも他のパッケージと同様に扱えよ」という設計思想なのである。
だからこの $GOPATH
は他のパッケージマネージャーのように単なるライブラリの参照先ではないのである。
動作的には $GOPATH/src
に自分のソースを配置しないと自分が Glade でダウンロードして配置したの vendor ディレクトリ内のパッケージを探しに行ってくれない。
Go はソースそのものがその場で動作するのではなく、コンパイルしたものが実行されるので、このように配置位置に柔軟性がなく管理優先になっていても問題ないという考え方なのだろう。
よくあるやつ。
$ glide init
質問がされるが、とりあえず No でファイルだけ作る
そうすると。glide.yaml というYAML形式のファイルが作られる。 Glide の設定は YAML で書く。
init で作られたファイルを見ると、こうなっている。
package: . import: []
package とは自分のパッケージを指していて、import に使いたいパッケージを指定する。
つまり、この import というキーに対してリストを書けということである
試しに、Excelを操作するライブラリを書いてみるとこうなる
package: . import: - package: github.com/tealeg/xlsx
ドン
$ glide update
これで何も指定しなくても vendor 以下にパッケージがインストールされる。 Glide にはグローバルに突っ込むというオプションは無くて常にローカルで管理される。