Golang dependency control

<p>I have read several ways to check dependencies. Shouldn&#39;t there be only one way to control the dependency flow with versioning? Is there a version control system which you suits you?</p> <p>(go get doesn&#39;t count. It doesn&#39;t manage dependencies.)</p> <hr/>**评论：**<br/><br/>ezlover111: <pre><p>+1 for gb</p></pre>dlsniper: <pre><p>I&#39;m using godep (github.com/tools/godep) for a while now and it does the jov for me. Also a search either here or on the mailing list would help you find other threads just like this. </p></pre>genesem: <pre><p>simple way <a href="https://gopkg.in" rel="nofollow">https://gopkg.in</a></p></pre>dchapes: <pre><p>I&#39;m always puzzled when someone mentions gopkg.in when dependency management is brought up.</p> <p>All gopkg.does is provide a way that a package author can use to version their package import path. Further, it <em>only</em> works with GitHub repositories! It helps not-at-all for someone trying to manage their project&#39;s dependencies. I have no control of which my dependencies are on GitHub, Bitbucket, LauchPad, code.google.com, etc and which choose to use gopkg.in. Further, it helps not at all when I depend on package A which imports gopkg.in/foo.v1 and package B which imports gopkg.in/foo.v2; unless you assume silently having two compiled in slightly different versions of foo is somehow always (ever?) the right thing.</p></pre>genesem: <pre><p>yeah, but only as an option when there is no other options.</p></pre>elithrar_: <pre><p>There are lot of options, but from my experience <a href="https://github.com/tools/godep">godep</a> and <a href="http://getgb.io/">gb</a> are probably the two standouts.</p> <p>Go itself will have some limited capability to build from vendored dependencies with the <code>-vendor</code> flag in (probably) 1.5 but there is no standardised manifest for tracking versions. This is partly because Go packages don&#39;t have their own concept of a version; only the VCS the package is in does.</p></pre>zeroXten: <pre><p>I&#39;ve ended up writing one for pki.io to match our requirements. </p> <p>We were using Gom but that was using upstream dependencies directly. We wanted full control of the supply chain, so we fork the dependencies into repos we own. I wrote fdm* to work in a similar way to Gom (GOPATH rewrite etc) but it works on the basis of forked dependencies. Basically, it clones from your fork and symlinks to a name matching the upstream. That way it avoids import rewriting, but at the moment it only works on *nix.</p> <ul> <li><a href="https://github.com/pki-io/fdm" rel="nofollow">https://github.com/pki-io/fdm</a></li> </ul> <p>Edit:</p> <p>I&#39;m actually in the middle of a major edit to work better with an automated supply-chain script I&#39;m going to write. This will ensure the forks are kept update to date. It will allow releases to be consistent but will allow dev to build against the latest upstream.</p></pre>