<p>I have been more interested in go vendoring recently trying to understand the way to use it and specifically I have tried to find a good starter tutorial on how to use it but I have not been successful. Can someone point me to a beginner go vendoring tutorial</p>
<p>Thanks</p>
<hr/>**评论：**<br/><br/>stackmutt: <pre><p>Use a vendoring tool. Good list and info at <a href="https://github.com/golang/go/wiki/PackageManagementTools">https://github.com/golang/go/wiki/PackageManagementTools</a> .</p>
<p>I'm a gvt kinda guy myself.</p></pre>dankcode: <pre><p>why isn't godep mentioned in this list? it's used by heroku for standard deploys.</p></pre>tamalm: <pre><ol>
<li>install godep. $ go get github.com/tools/godep</li>
<li>create 'vendor' folder in your project root dir.</li>
<li>run $ godep save (this will do the magic). Check vendor folder. You'd see all dependencies.</li>
</ol>
<p>Now every 'go build' will look for packages in the vendor folder (NOT $GOPATH/pkg or /src folder).</p>
<p>EDIT: You are free to use any other go vendor tools. <a href="https://github.com/golang/go/wiki/PackageManagementTools#go15vendorexperiment" rel="nofollow">https://github.com/golang/go/wiki/PackageManagementTools#go15vendorexperiment</a></p></pre>pafortin: <pre><p>This worked great - thanks... One more question is there a way to verify that go build / go run is using the dependancies in the vendor folder?</p></pre>tamalm: <pre><p>yep!</p>
<p>$ go build -v </p></pre>pafortin: <pre><p>Worked flawlessly - thank you...</p>
<p>➜ vendortest go build -v<br/>
vendortest/vendor/gopkg.in/mgo.v2/internal/scram
vendortest/vendor/gopkg.in/mgo.v2/bson
vendortest/vendor/gopkg.in/mgo.v2
vendortest</p></pre>alexfiori: <pre><p>You don't have to create the vendor directory yourself. The first <code>godep save</code> will do it.</p></pre>anacrolix: <pre><p>When was godep changed to work like this?</p></pre>agentargo: <pre><p>I don't know why, but it drives me nuts that godep creates its own folder in CamelCase to store a single file. </p></pre>nicerobot: <pre><p>I wrote <a href="https://github.com/nicerobot/git-freeze"><code>git-freeze</code></a> to make vendoring as simple as possible. Write your Go application as usually, install <code>git-freeze</code>, then run <code>git freeze</code>.</p></pre>motojo: <pre><p>Vendoring in Go is pretty easy. I'll explain how to do it manually so you can understand what the many vendoring tools are actually doing.</p>
<p>Go 1.5 supports an experimental feature which allows you to store the external packages you use in a folder called <strong>vendor</strong>. In Go 1.6, the feature is enabled by default. You can enable the feature in 1.5 by setting this environment variable: GO15VENDOREXPERIMENT=1</p>
<p>To test vendoring on a current project, simply move all the external packages to a folder called <strong>vendor</strong> in the root of your project and your program should continue to compile without any errors. You don’t have to change any import paths. If you have the same package inside the vendor folder and outside your package folder, the one in the vendor folder will be used.</p>
<p>Source: <a href="http://www.josephspurrier.com/how-to-use-go15vendorexperiment/">http://www.josephspurrier.com/how-to-use-go15vendorexperiment/</a></p></pre>anacrolix: <pre><p>I think the link to official doc on this is better.</p></pre>andreynering: <pre><p><a href="https://github.com/kardianos/govendor" rel="nofollow">govendor</a> is much better than Godeps.</p></pre>pafortin: <pre><p>What makes it so much better?</p></pre>andreynering: <pre><p>Some of your dependencies may also have the vendor folder, and some of its dependencies may have vendor folders, too. And so on...</p>
<p>govendor will flattens all dependencies in a single vendor folder and just work, while Godeps will fail a lot of times asking you to go get a missing package. It will search only in your GOPATH, but not on nested vendor folders.</p>
<p>Also, Godeps also copies test files, while govendor not.</p></pre>danieldk: <pre><p><em>Some of your dependencies may also have the vendor folder, and some of its dependencies may have vendor folders, too. And so on...</em></p>
<p>But that should be considered to be a bug in that package, no? As far as I understood the rule is: packages -> no vendoring, binaries -> vendoring. Or in the words of Andrew Gerrand:</p>
<p><a href="https://groups.google.com/d/msg/golang-dev/nMWoEAG55v8/GXh7DT7HknoJ" rel="nofollow">https://groups.google.com/d/msg/golang-dev/nMWoEAG55v8/GXh7DT7HknoJ</a></p>
<p>Also note that the govendor whitepaper suggests bad practices:</p>
<p><a href="https://github.com/kardianos/govendor/blob/master/doc/whitepaper.md#package-developers" rel="nofollow">https://github.com/kardianos/govendor/blob/master/doc/whitepaper.md#package-developers</a></p>
<p>Packages should not use semver. semver is used to mark breaking API changes. In Go an import path should be API-stable.</p></pre>andreynering: <pre><p>Yes, I think it's a bug in Godeps. I think there's a issue on GitHub also.</p>
<blockquote>
<p>Packages should not use semver. semver is used to mark breaking API changes. In Go an import path should be API-stable.</p>
</blockquote>
<p>That's debatable. Not using semver means you can't do breaking changes, but sometimes it is necessary. I prefer the use of <a href="https://gopgk.in" rel="nofollow">https://gopgk.in</a> for this, though.</p></pre>danieldk: <pre><p><em>I prefer the use of <a href="https://gopgk.in" rel="nofollow">https://gopgk.in</a> for this, though.</em></p>
<p>Same thing here! Creating new namespaces is the way to go.</p></pre>jostyee: <pre><p>it's <a href="https://gopkg.in" rel="nofollow">https://gopkg.in</a></p>
<p>And yes, it's very helpful when you depend on public repos on GitHub.</p></pre>pafortin: <pre><p>Oh excellent I will try govendor then....</p></pre>agentargo: <pre><p>I've had annoyances with govendor copying the stdlb or my subpackages. I'm sure this is from me misusing the commands, but I really think it could use either sane defaults or a better usage/quick start section of the readme.</p></pre>andreynering: <pre><p>Hmm... It should be as simple as running <code>govendor add +external</code>. Otherwise, open an issue.</p></pre>pkieltyka: <pre><p>I highly recommend a look at <a href="https://github.com/kardianos/govendor" rel="nofollow">https://github.com/kardianos/govendor</a> for pkg mgmt and vendoring in Go. The project has iterated a lot since the Go 1.5 vendor experiment, the code base is very clean, easy to work with and powerful. The docs are still being improved, but if someone has a question just open an issue (I've talked to the author a bunch and he's very bright and responsive)</p></pre>qu33ksilver: <pre><p>Here you go - <a href="http://www.goin5minutes.com/screencast/episode_7_vendoring_your_dependencies_in_go/" rel="nofollow">http://www.goin5minutes.com/screencast/episode_7_vendoring_your_dependencies_in_go/</a></p>
<p>Nice beginner video.</p></pre>pafortin: <pre><p>So from that comment I gather there is no built in "go" vendoring command like "go vendor get XXX/XX/XX". That is kinda what confuses me since the "go" command does so much stuff already I would have though it did this already since it is idiomatic now since 1.6. Is there a plan for such a tool?</p></pre>: <pre><p>[deleted]</p></pre>pafortin: <pre><p>Inside my GOPATH or my project directory? If it is in GOPATH how is that different than the normal "go get ..." without a vendor directory? </p></pre>nerdwaller: <pre><p>The <a href="https://golang.org/cmd/go/" rel="nofollow">documentation</a> (any my own experience) has suggested this doesn't work.</p>
<blockquote>
<p>Get never checks out or updates code stored in vendor directories.</p>
</blockquote>
<p>You need a 3rd party tool to do it</p></pre>comrade_donkey: <pre><p>you're completely right. I deleted my comment.</p></pre>kaeshiwaza: <pre><p>Is there a reason to use /vendor when you have one GOPATH per project ?</p></pre>pafortin: <pre><p>In my opinion if you set your gopath for each project then go vendoring maybe useless but I defer to others here that have a lot more experience in go vendoring than me (the noob :-))</p></pre>alexfiori: <pre><p>No reason.</p></pre>kaeshiwaza: <pre><p>Then, when is it better to don't use one GOPATH per project ?</p></pre>pafortin: <pre><p>I believe that if you had 2 projects and they both depended on 1 package but not the same version of it then just using a GOPATH would not work (in comes vendoring so each project can use the version it needs without breaking the other one)</p></pre>kaeshiwaza: <pre><p>When I have 2 projects I have 2 GOPATH... I do exactly like virtualenv in Python.</p></pre>toelint: <pre><p><del>It's supported in go 1.6. If your project has a /vendor directory, go get will install there.</del></p>
<p><a href="https://blog.golang.org/go1.6" rel="nofollow">https://blog.golang.org/go1.6</a></p>
<p><a href="/u/ngrilly" rel="nofollow">/u/ngrilly</a> is quite right. You can manually put folders into /vendor/ and call them within your application but <code>go get</code> doesn't put them there. Looks like one of the other solutions would be easier.</p></pre>ngrilly: <pre><blockquote>
<p>If your project has a /vendor directory, go get will install there.</p>
</blockquote>
<p>I don't think so.</p>
<p>"Vendor directories do not affect the placement of new repositories being checked out for the first time by 'go get': those are always placed in the main GOPATH, never in a vendor subtree."</p>
<p>Source: <a href="https://golang.org/cmd/go/#hdr-Vendor_Directories" rel="nofollow">https://golang.org/cmd/go/#hdr-Vendor_Directories</a></p></pre>earthboundkid: <pre><pre><code>GOPATH=/tmp/vendor go get github.com/whatever
cp /tmp/vendor/src project/vendor
</code></pre>
<p>That's enough for a simple project. </p></pre>
