Have we come to a consensus on dependency management?

<p>One of the problems I&#39;ve run into recently is poor dependency management for my Go projects, with dependencies causing breakages after accidentally wiping away a GOPATH and downloading the latest versions. </p> <p>This was my fault, but I was just wondering, has the community come to a good solution for fixing this issue? I know there are a few systems like godep out there that offer a more managed approach, but is this widely accepted as the standard approach?</p> <hr/>**评论：**<br/><br/>zond: <pre><p>I have had an excellent experience using <a href="http://godoc.org/github.com/mjibson/party">http://godoc.org/github.com/mjibson/party</a></p> <p>It automates the &#34;copy deps to a subdirectory and change all import paths&#34; task, nothing else.</p> <p>No config file, no tags, no comments necessary. </p> <p>Manage your deps manually by updating them in your GOPATH using &#39;git&#39; and &#39;go get&#39;, then update everything in your vendor dir with a single &#39;party&#39; invocation.</p></pre>djhworld: <pre><p>Very interesting, will check it out - thanks!</p></pre>kron4eg: <pre><p>yes, vendor as much as you can</p></pre>noydoc: <pre><p>I&#39;m not sure we will ever. It&#39;s not a problem Google has.</p> <p>My biggest criticism of golang is how painful it can be when Google&#39;s use-case is different than mine, or yours.</p></pre>: <pre><p>[deleted]</p></pre>noydoc: <pre><p>The community has created several independent solutions without consensus.</p> <p>Google has the ability to embed dependency management into the go binary beyond <code>go get</code>. This would force consensus onto the community.</p></pre>anacrolix: <pre><p>Fork Go and pull their lame GC and bug fixes.</p></pre>jimuazu: <pre><p>There is a recommended approach here from the Go team: <a href="https://groups.google.com/forum/m/#!topic/golang-dev/nMWoEAG55v8">https://groups.google.com/forum/m/#!topic/golang-dev/nMWoEAG55v8</a></p></pre>esdffffffffff: <pre><p>Yup, this is the answer. For me, i&#39;m changing nothing, and waiting till 1.5. Then converting everything to that.</p></pre>om0tho: <pre><p>Same.</p></pre>gogolang: <pre><p>I tend to fork a lot and use forked versions</p></pre>robertmeta: <pre><p>If you are writing an application -&gt; vendor using tool of your choice (godeps, etc)</p> <p>If you are writing a library -&gt; gopkg.in</p></pre>silent__thought: <pre><p>I wish the Go project would adopt gopkg.in like they did godoc.org. Excellent project and core to the ecosystem IMO.</p></pre>avrtno: <pre><p>Godoc.org works without the cooperation of the package author.</p> <p>Gopkg.in requires the cooperation of the package author. </p> <p>Many people think that gopkg.in solves problems that it does not actually solve. </p></pre>silent__thought: <pre><p>Honestly the only feature I care about is that I&#39;m able to maintain multiple API versions in the same repo. As a package writer that frustrates the heck out of me with &#34;go get&#34;.</p></pre>zond: <pre><p>You can do that anyway. Compare <code>github.com/zond/someproject/v1/somepackage</code> and <code>github.com/zond/someproject/v2/somepackage</code>. </p></pre>silent__thought: <pre><p>I&#39;m a bit embarrassed to admit that hadn&#39;t occurred to me. Thanks!</p></pre>robertmeta: <pre><blockquote> <p>Gopkg.in requires the cooperation of the package author. </p> </blockquote> <p>For beyond v0, absolutely. I don&#39;t consider this a flaw. </p> <blockquote> <p>Many people think that gopkg.in solves problems that it does not actually solve. </p> </blockquote> <p>What is the misunderstanding people have about it?</p></pre>robertmeta: <pre><p>I like gopkg.in -- but am not to the point I would like it blessed yet. </p></pre>