web-dev-qa-db-ja.com

Go 1.6でベンダーを使用するにはどうすればよいですか？

最初にこの答えを読みました： Go 1.6のVendoring 、次にそれを例として使用します。

私のgopathはGOPATH="/Users/thinkerou/xyz/"、および次のようなもの：

thinkerou@MacBook-Pro-thinkerou:~/xyz/src/ou$ pwd
/Users/baidu/xyz/src/ou
thinkerou@MacBook-Pro-thinkerou:~/xyz/src/ou$ ls
main.go vendor

今、私はgo get、そしてこれになります：

thinkerou@MacBook-Pro-thinkerou:~/xyz/src/ou$ ls
main.go vendor
thinkerou@MacBook-Pro-thinkerou:~/xyz/src/ou$ cd vendor/
thinkerou@MacBook-Pro-thinkerou:~/xyz/src/ou/vendor$ ls
vendor.json
thinkerou@MacBook-Pro-thinkerou:~/xyz/src/ou/vendor$ cd ../..
thinkerou@MacBook-Pro-thinkerou:~/xyz/src$ ls
github.com ou
thinkerou@MacBook-Pro-thinkerou:~/xyz/src$ cd github.com/
thinkerou@MacBook-Pro-thinkerou:~/xyz/src/github.com$ ls
zenazn

vendor.json これは：

{
    "comment": "",
    "package": [
        {
            "path": "github.com/zenazn/goji"
        }
    ]
}

次に、どのコマンドを使用する必要がありますか？なぜvendorを使用しないのですか？ Goバージョンは1.6.2です。

govendor
32
thinkerou

Go1.6では、読んでいるとおりにベンダー化が組み込まれています。これは何を意味するのでしょうか？念頭に置いておくべきことは1つだけです。

go buildやgo runなどのgoツールを使用する場合、最初に依存関係が./vendor/にあるかどうかを確認します。もしそうなら、それを使用します。そうでない場合は、$GOPATH/src/ディレクトリに戻ります。

Go 1.6の実際の「ルックアップパス」は次の順序です。

./vendor/github.com/zenazn/goji
$GOPATH/src/github.com/zenazn/goji
$GOROOT/src/github.com/zenazn/goji

そうは言っても、go getは引き続きインストールされます$GOPATH/src;また、go installは、バイナリの場合は$GOPATH/binに、パッケージキャッシュの場合は$GOPATH/pkgにインストールされます。

だから、どのように./vendorを使用しますか？！？！

上記の知識を備えたHeheは、非常に簡単です。

mkdir -p $GOPATH/src/ou/vendor/github.com/zenazn/goji
cp -r $GOPATH/src/github.com/zenazn/goji/ $GOPATH/src/ou/vendor/github.com/zenazn/goji

つまり、ベンダー化を使用するには、同じgithub.com/zenazn/gojiフルパスを使用してファイルをベンダーディレクターにコピーします。

これで、go build/install/runツールがベンダーフォルダーを確認して使用します。

すべてを手動でコピーするよりも簡単な方法

25以上のすべてのベンダーアイテムを見つけてコピーする代わりに、バージョンを管理し、他のプロジェクトを更新するなど... 依存関係管理ツールを使用する方がよいでしょう。そこには多くのものがあり、少しグーグルはいくつかを指します。

ベンダーフォルダーで機能し、あなたと戦わない2つを挙げましょう。

  • ゴデップ
  • 仕掛け人

要するに、これらのツールはouコードを検査し、リモートの依存関係を見つけ、それらをコピーしますfrom your $GOPATH/srcto your $GOPATH/src/ou/vendorディレクトリ（実際には、実行時に現在のディレクトリが何であれ）。

たとえば、依存関係の通常のGOPATH/src/githubインストールを使用して、$GOPATH/src/ou/プロジェクトにすべての依存関係がインストールされ、正常に動作しているとします。プロジェクトが実行され、テストにより、すべてがリポジトリの正確なバージョンで機能していることが検証されます。例としてGodepを使用すると、プロジェクトのルートフォルダー$GOPATH/src/ou/からこれを実行します。

godep save ./...

これにより、プロジェクトが使用するすべての依存関係が./vendorフォルダーにコピーされます。

ゴデップは圧倒的に大人気です。 Gopher Slackグループに独自のSlackチャネルがあります。そして、それは私のチームで使用するものです。

Govendorは、私が読むもう1つの代替手段であり、Nice同期機能を備えています。しかし、私はそれを使用していません。

依存関係管理ツールの過剰使用

これは純粋に意見であり、嫌悪感は否定するだろうと確信しています...しかし、このテーマに関するブログの投稿を終える必要があるので、ほとんどの人がGoの依存関係管理についてあまりにも心配していることをここで言及します。

はい。システムを本番環境でビルドできるように、依存するバージョンのリポジトリをロックする必要があります。はい、依存関係が何かを中断している方法に重大な変更を加えないようにする必要があります。

これらには絶対に依存関係管理を使用してください。

しかし、実際には膨大な依存関係をロックする単純なプロジェクトの使いすぎがあります...

ロックする必要がある依存関係は1つだけです。それ以外の場合は、MySQLドライバーの最新バージョンが必要であり、バグ修正のためにアサーションフレームワークをテストします。

これは、依存関係管理ツールとは別に./vendor/フォルダーを使用すると本当に輝ける場所です。ロックする必要があるレポのみをコピーする必要があります。

不正なレポを選択して選択し、。/ vendor /フォルダーに配置します。これにより、消費者に次のことを伝えます。

ねえ、この1つのレポはこの改訂で控える必要があります。他のすべては問題なく、それらの最新のものを使用し、go get -u ./...で頻繁に更新します。しかし、これは新しいバージョンで失敗したため、このリポジトリをアップグレードしないでください。

ただし、依存関係管理ツールを使用してすべての依存関係を全面的に保存する場合、基本的には消費者に次のように伝えます。

ベンダーフォルダー内の20個のうち1個以上のリポジトリに問題がある場合とない場合があります。それらを更新できる場合とできない場合があります。最新のMySQLドライバーを入手できる場合とできない場合があります。どちらが問題を引き起こしているのか、または引き起こしていないのかがわからず、私がgodep saveを実行したときに機能していたものにロックされているだけです。そう、あなた自身の責任でアップグレードしてください。

個人的には、これに何度か遭遇しました。依存関係が重大な変更で更新され、それに依存するリポジトリが多数あります。/vendorでその1つのレポだけをベンダー化すると、そのバージョンの依存関係を使用できますが、go get ./...は他のすべてのレポで最新の状態を維持するために通常どおり実行されます。 PSQLやMySQLなどの最新のバグ修正（これらには常に修正があります！）などを実行します。

77
eduncan911