State of Vendoring

<p>Having not really followed any of the Go community over the past year or so what is the direction being taken in terms of vendoring and what it considered best practice at this time? I know that in 1.6 the vendoring experiment introduced in 1.5 is going to become the default and that there are now many tools that work with this. I&#39;ve also seen gb pop up as an alternative to the go tool. Is there a general move to gb overall? One of the concerning issues about gb currently is the lack of go getability, which makes sense given that it&#39;s designed for projects not libraries. That being said, what are the reasons to use gb over the go tool, with the convention of the cmd directory for mains, with the vendoring experiment and picking one of the other tools designed to copy dependencies into the vendor directory?</p> <hr/>**评论：**<br/><br/>karnd01: <pre><p>speaking strictly about vendoring, IMHO I will be keeping my distance and using <a href="http://labix.org/gopkg.in" rel="nofollow">http://labix.org/gopkg.in</a> like @robertmeta stated until an agreed upon/standardized vendoring file format is used by/agreed upon the mass majority of tools support it.</p> <p>Until that happens I think that vendoring may be a little bit of chaos, for example: Project A vendors Project B using tool X using format 1 Project B vendors project C using tool Y using format 2 Project C vendors project D using tool Z using format 3</p> <p>so now I need tool X, Y and Z because of the different file formats supported, just to load all my projects dependencies? unless I&#39;m missing some key concept of vendoring</p></pre>hayzeus: <pre><p>Depends -- if the vendored code is committed with the project you need nothing other that GO15VENDOREXPERIMENT set (assuming gb was not used), although there are hazards to including vendored code with a package.</p></pre>izuriel: <pre><p>Glide is great for this as it will handle not only its own censoring format bit Godeps and I believe gb too. I&#39;ve had nothing but pleasure working with it. </p></pre>ChristophBerger: <pre><p>+1 for <a href="https://github.com/Masterminds/glide" rel="nofollow">Glide</a>. Easy to use and quite versatile. It also has some useful commands for inspecting and updating the vendor tree. And it can handle code that is vendored by Godeps, gb, and GPM.</p></pre>karnd01: <pre><p>Thanks I&#39;ll definitely give glide a look</p></pre>robertmeta: <pre><p>I don&#39;t know about the state of Go generally -- but our team has rather happily ended up with. </p> <ul> <li>gb for projects :: <a href="https://getgb.io/" rel="nofollow">https://getgb.io/</a></li> <li>gopkg for libraries :: <a href="http://labix.org/gopkg.in" rel="nofollow">http://labix.org/gopkg.in</a></li> </ul> <p>Seems to solve most of the pain points and follow the logical progression of work. We specifically use <strong>gb vendor</strong> as well. </p></pre>elithrar_: <pre><p>Ditto, but using gvt (<a href="https://github.com/FiloSottile/gvt">https://github.com/FiloSottile/gvt</a>) over gb. I really want to be able to provide different library versions outside of gopkg.in, but that&#39;s not an option sadly. </p></pre>siwu: <pre><p>+1 for gvt (which is gb + GO15VENDOREXPERIMENT)</p></pre>callcifer: <pre><p>Another +1 for gvt. It&#39;s simple, tiny and only does one thing: putting a dependency (recursively) into <code>/vendor</code>. Your project still works with <code>go get</code> and <code>go build</code>.</p></pre>om0tho: <pre><p>+1 for gvt for working with <code>go get</code> and <code>go build</code>.</p></pre>robertmeta: <pre><p>Wow -- I had never even heard of gvt -- it is good stuff! Man, I might have to switch to it! NOOOOOOOOOOOOOO, I just made work for myself. </p></pre>