<p>I want to ask, which dependency management tool are you using gb or godep?<br/>
Thanks</p>
<hr/>**评论：**<br/><br/>syf81: <pre><p>We've switched over from godep to <a href="https://github.com/Masterminds/glide">glide</a>.</p></pre>-Nii-: <pre><p>I just switched from glide to godep! I'll come back to it when go 1.6 is out.</p></pre>mattfarina: <pre><p>Is there something that was a problem? I'm happy to look at that before go 1.6 comes out.</p></pre>-Nii-: <pre><p>Matt, I discussed the issue <a href="https://github.com/Masterminds/glide/issues/81" rel="nofollow">here</a> with you. </p>
<p>Basically <code>gocode</code> will not support <code>GO15VENDOREXPERIMENT</code>, and <code>glide rebuild</code> does not put the <code>.a</code> files in the correct place for <code>gocode</code> to function correctly.</p>
<p>For the moment, <code>godep</code> does do what I need it to do but I'll be happy to switch to glide if I can get my autocomplete working!</p></pre>mattfarina: <pre><p>Ah, sorry I didn't put it together that it was you in both places.</p>
<p>Once gocode is willing to put the change in I'm happy to help. gocode supporting the vendor directory well will be a benefit for everyone. Not just glide users.</p></pre>-Nii-: <pre><p>I agree totally! Its just that without <code>gocode</code> autocompletion, I lose a large chunk of my productvity. Which is why I mentioned I'm waiting for Go 1.6. Not because of Glide, but because of Gocode =)</p></pre>dlsniper: <pre><p>glide is a better choice imo.</p></pre>pkieltyka: <pre><p>Both are great tools, but I'd like to see how they evolve when Go's vendor mechanics are the default in 1.6. </p>
<p>Personally, I use GO15VENDOREXPERIMENT for building and just wrote a simple program (<a href="https://github.com/pressly/gv" rel="nofollow">https://github.com/pressly/gv</a>) to copy packages from $GOPATH to <code>./vendor/</code> and use a Makefile to build/update packages. I also use glock (<a href="https://github.com/robfig/glock" rel="nofollow">https://github.com/robfig/glock</a>) to sync package versions to my $GOPATH. However, I think glock or any package management tool needs a major haircut to be directly designed for the new vendoring.</p>
<p>the Makefile I use for all my projects....: <a href="https://gist.github.com/pkieltyka/f5c493fb2f63ef7bc76b" rel="nofollow">https://gist.github.com/pkieltyka/f5c493fb2f63ef7bc76b</a></p>
<p>btw, it requires Go 1.5 for its vendoring support. And also make sure to commit vendor/ in your VCS as well and use <code>make dist</code> when building binaries for distribution.</p></pre>bketelsen: <pre><p>I love gb. No surprises, no craziness, just works.</p></pre>fern4lvarez: <pre><p>As a developer, do I need gb installed to start working with your gb-based project? <code>git clone</code> is enough? the lack of support for <code>go get</code> concerns me. What if I want to use a library from your project on my GOPATH-living project?</p></pre>bketelsen: <pre><p>gb is designed to build your commands (executables) If you're building a library, you can still use gb because it respects and understands the gopath. in short, gb usage doesn't change the world's view of your project.</p></pre>jwoongkim: <pre><p>if you are on go 1.5 (GO15VENDOREXPERIMENT support) and don't want to change the build tool, check out the <a href="https://github.com/FiloSottile/gvt" rel="nofollow">gvt</a></p></pre>zero_coding: <pre><p>I am very confuse now, I am using Go 1.5 and what should I use for build tool?</p></pre>kylewolfe: <pre><p>Another build tool is not a necessity for GO15VENDOREXPERIMENT.</p></pre>mattfarina: <pre><p>I wrote up a quick into to the new vendor system at <a href="http://engineeredweb.com/blog/2015/go-1.5-vendor-handling/" rel="nofollow">http://engineeredweb.com/blog/2015/go-1.5-vendor-handling/</a>. The setup is useful but the details don't appear to be widely known, yet. Hope it helps.</p></pre>kylewolfe: <pre><p>Go's new built in vendoring (as of 1.5). Go 1.6 will have it on by default.</p></pre>THEHIPP0: <pre><p>I use godep with GO15VENDOREXPERIMENT enabled, which works pretty good for me. I barely need to touch godep, other when updating or adding a dependency.</p></pre>jhonghee: <pre><p>In terms of vendoring, I don't see any one tool standing out. They all work pretty well. I've used govendor and gvt with GO15VENDOREXPERIMENT enabled. Works fine. But I have to say that GB project excites me. I would like to see more IDE/editor plugins supporting GB although it's not difficult to configure them for GB at all. For example, if golang plugin for Intellij automatically adjust its go env settings by detecting "vendor" folder would be very cool. Since GB allow you have project based build, it also works well with other eco-systems. I can easily imagine myself adding grunt or gulp build along side with gb build in CI.</p></pre>aboukirev: <pre><p>Looking at various tools I can see that some (gvt, glide) assume dependencies to be directly in vendor sub-folder, and some other (gb, gocode) assume that dependencies live in vendor/src sub-folder. I need gocode to work for autocomplete. How does one reconcile these differences?</p></pre>mattfarina: <pre><p>The GO15VENDOREXPERIMENT that will be on by default in go 1.6 and is opt-in for go 1.5 assumes dependencies will be in the vendor/ folder.</p>
<p>gocode isn't going to support the GO15VENDOREXPERIMENT until it's on by default. There's an <a href="https://github.com/nsf/gocode/issues/296" rel="nofollow">open issue on the topic</a>.</p>
<p>The vendor/src folder setup is typically a hold over from a work around prior to the GO15VENDOREXPERIMENT. One could put the vendor/ folder in the GOPATH and go would look for the vendor/src folder. We used to do something like that on glide in the early days.</p>
<p>gb is a build tool separate from the go build tool. It can look for vendor dependencies where it chooses since it builds the executables rather than the go tool. I'm not sure of their future plans but Dave Cheney is usually pretty good at thinking these things through. I expect that whatever path they take will be thought out.</p></pre>aboukirev: <pre><p>Thanks.</p>
<p>And that above is the reason I am reluctant to move to new vendoring. So far, all my packages are in the same global GOPATH location. Has worked well so far while maintaining 5 separate projects simultaneously between 3 developers.</p>
<p>I used to work on nodejs projects and liked vendoring there, especially when they made npm look for the module up tree to avoid pulling a duplicate down the branch.</p></pre>mattfarina: <pre><p>First, I'm one of the authors of glide which means you can feel free to ask questions and you know where my bias is up front.</p>
<p>gb isn't a vendoring tool. gb-vendor, the plugin for gb is the vendoring component. gb is a project based build tool that replaces uses parts of the go tool. I put this in because it appears there is, at times, some confusion.</p>
<p>That makes gb-vendor a little different from godep and glide which are designed to work with the go build tool.</p>
<p>While I can't speak directly to the roadmap and plans for godep I can tell you that glide is headed down the same road as Cargo (Rust), npm (node.js), composer (php), and the others for the other languages. We are attempting to do it in a Go way and play nicely with all the VCS the go tool works with.</p>
<p>Again, I'm happy to answer any questions. You can find me in #masterminds on freenode IRC or the <a href="https://github.com/masterminds/glide/issues" rel="nofollow">glide issues</a> on a typical weekday which is more often that I check back here.</p></pre>marcotr: <pre><p>most people seem to be more than happy with gb...</p></pre>zero_coding: <pre><p>and with glide?</p></pre>wlll: <pre><p>I use <a href="https://github.com/nitrous-io/goop" rel="nofollow">goop</a>, though I might check out glide, not seen it before.</p></pre>
