Best dependency management tool for Go?

<p>One of my main concerns around choosing golang for a new project is that there don&#39;t seem to be &#34;production ready&#34; dependency management tools available.</p> <p>How do you all manage your dependencies? Pulling the latest commit off master off some random github repo and hoping for the best scares me a bit...</p> <p>I saw <code>dep</code> is available, but appears to be in alpha/beta status. Is anyone using it and how easy is it to work with?</p> <p>Ideally I&#39;m looking for something with a CLI similar to NuGet or npm (coming from JavaScript + C# land), where I can just run something like <code>name-of-tool install name-of-package@^2.0.0</code></p> <p>Thanks!</p> <hr/>**评论：**<br/><br/>zekjur: <pre><p>Just use dep. It works fine :)</p></pre>TrueFurby: <pre><p>And also current status says it&#39;s ready for production use: <a href="https://github.com/golang/dep#current-status" rel="nofollow">https://github.com/golang/dep#current-status</a></p></pre>PerfectlyCromulent: <pre><p>I&#39;ve been using dep for about a month and I&#39;ve had plenty of instances where it absolutely does not &#34;work fine&#34;. If you use it, be prepared to occasionally hunt through transitive dependencies for specific version requirements that didn&#39;t get correctly resolved by dep. There are even some fairly well known libraries, the Kubernetes client-go library for example, that advise against using dep.</p> <p>That being said, I&#39;ve been able to work around most of the issues I&#39;ve had with dep and I imagine it will continue to improve. It still feels very much like a beta version, though.</p></pre>Dgt84: <pre><p>You should use <code>dep</code> unless you have a good reason not to. It is going to be the official tool, the <code>Gopkg.toml</code> format is locked, and the command line interface is mostly locked. We&#39;ve been using it for months in production environments.</p> <p>Instead of <code>npm install package@version</code> you do <code>dep ensure --add package@version</code> (or if you already use the import in your code, just <code>dep ensure</code> will pick it up).</p> <p>Don&#39;t fret - the Go dependency problem is almost solved. Now we just need to convince everyone to use semantic versioning and push their tags to GitHub. That&#39;s not as easy to fix!</p></pre>monoxiphoid: <pre><p>Alright, you&#39;ve convinced me. I&#39;ll just use dep. But yeah, I&#39;m a little worried about the whole lack of tags thing. I&#39;ve already seen a couple libraries that don&#39;t use them at all and just push stuff to master. I suppose I could always fork at a certain commit and then create my own tag to get around that issue.</p></pre>zevdg: <pre><p>You don&#39;t need to do all that. Dep has fairly sane behavior for libraries without any tags. It will start you out with the latest version, but it is smart enough to never update the version of a dependency unless you explicitly ask it to or some other dependency specifically requires it to. So you can still use untagged repositories with a reasonable amount of confidence as long as you check in your lockfile. If you&#39;re paranoid, just review any changes dep makes to the lockfile when you check them in. </p> <p>The only case that is particularly problematic is when a library did tag versions a long time ago but hasn&#39;t tagged anything recently. Then dep&#39;s default behaviour of using the latest tagged release (even if it is super out of date) is generally not what you want. However, most library owners are very open to tagging a release if you ask them to, and you can always manually constrain or override the version for a few days until they get around to it. Just remember to remove the constraint/override when they do!</p> <p>In the very worst case, you can always manually pin to a specific git commit, but most of the time, that&#39;s unnecessary and harmful in the long run. Learn to stop worrying and love the lockfile.</p></pre>SeerUD: <pre><p>TL;DR: Like most other package managers, dep uses a lock file to lock versions once they&#39;re retrieved the first time. Subsequent installs will install that same version.</p></pre>tree_hau5: <pre><blockquote> <p>It is going to be the official tool,</p> </blockquote> <p>Is this true? So far everything I heard from core team members has been to shy away from blessing this as the official yet. The perspective to have, at least as I have been lead to believe, is to consider this the &#34;official experiment&#34; but not to take it so far to call it the official tool, yet.</p> <blockquote> <p>Now we just need to convince everyone to use semantic versioning and push their tags to GitHub.</p> </blockquote> <p>I think a public package repository solves this similar to npm. Is that idea still being floated around? </p></pre>justinisrael: <pre><p>I still use glide because it works in the situation where I am in a limited proxy environment and part of my dependencies are internal gitlab repos that don&#39;t use a proxy and some are external that use the proxy. I tried to switch to dep and it basically doesn&#39;t work for me in this situation. I was given reasons related to how it treats the source vs name, etc. Basically I couldn&#39;t get it to work in a mixed proxy environments and gave up and stuck with glide. At least with glide I can specify all the information it requires for the internal repos so that it doesn&#39;t complain about them and uses the proxy properly for the github deps. </p></pre>GentooMonk: <pre><p>I personally use <a href="https://github.com/OneOfOne/git-go-vendor" rel="nofollow">https://github.com/OneOfOne/git-go-vendor</a> just because I don&#39;t have to maintain any extra config files with it.</p> <p>Of course that only works with git so ymmv.</p></pre>lstokeworth: <pre><p>We clone all of our dependencies and use a shell script to setup a Go workspace using the appropriate git commands. This is super simple and rock solid.</p> <p>This simple approach works because the Go development tools that we use don&#39;t care one wit about how the workspace is constructed.</p> <p>The script is checked into our repo. We update our git clones and the shell script as needed.</p></pre>kostix: <pre><blockquote> <p>there don&#39;t seem to be &#34;production ready&#34; dependency management tools available.</p> </blockquote> <p>No, you confuse this with &#34;there are no <em>officially blessed</em> dependency management tools available.&#34;</p> <p>Having worked through this, I&#39;d put my 2 ¢:</p> <ul> <li>Here at my $dayjob we&#39;re using <code>govendor</code> because we vendor all the dependencies to not be bitten by network outages or political-correctness outbreaks of lunatics at that popular Git hosting service which can suddenly make any of your dependencies unavailable.</li> <li><p>The <code>dep</code> tool <em>is</em> an officially-blessed one, finally. Supposedly it&#39;s not 100% polished, but it</p> <ul> <li>Reportedly works just fine for people.</li> <li>Is scheduled to be eventually integrated under the <code>go</code> tool umbrella.</li> </ul></li> </ul> <p>My personal opinion is to just pick <em>any random</em> vendoring tool — be it <code>glide</code>, <code>govendor</code>or whatnot and use it until you</p> <ul> <li>Better understand where the chosen tool sucks.</li> <li>Find a better alternative, if any.</li> </ul> <p>Thinking too much about such things up-front is fruitless because it&#39;s exactly like with performance optimizations: you <em>can</em> do certain estimations before actually writing code, but only profiling it under a real workload is able to show you where the bottlenecks are.</p> <p>We picked <code>govendor</code> (actually, an employee which was assigned the task of picking a tool for vendoring) almost at random — by trying it, seeing it works and making sure its upstream is responsive (and it really is — kudos to <a href="/u/kardianos" rel="nofollow">/u/kardianos</a>!).</p> <p>To recap: there are no <em>ideal</em> tools; there are different tools, and most of them are mature enough to work just OK. All of them have bugs, but there&#39;s nothing strange about this — Go itself has them, too. ;-) So don&#39;t be too attached to the idea of picking an ideal solution.</p></pre>tex0: <pre><p>Same here. At my $dayjob we also switched to govendor after using Godep for some time. Godep was OKish, but it had some issues and the workflow was a little annoying. So we evaluated, and actually used for some time, different vendoring tools. govendor seemed to be the most sane choice back then so we stuck with it. This was before go dep and the official vendor support existed.</p> <p>Since go dep was announced we keep an close eye on it and will probably switch some day, but so far it didn&#39;t seem to be mature enough (the last time we tried we immediately hit a critical bug).</p></pre>kostix: <pre><p>Same here indeed: we picked <code>govendor</code> when <code>dep</code> was in its infancy and might consider switching to <code>dep</code> eventually.</p> <p>But as of now this would not buy as anything.</p></pre>taylorchu: <pre><p>I evaluated many active vendoring tools by vendoring some big projects like docker, and <code>govendor</code> is the mature one. People at hashicorp use it as well. </p></pre>tv64738: <pre><blockquote> <p>The dep tool is an officially-blessed one, finally.</p> </blockquote> <p>&#34;dep is the official experiment, but not yet the official tool.&#34; <a href="https://github.com/golang/dep" rel="nofollow">https://github.com/golang/dep</a></p></pre>pemungkah: <pre><p>We&#39;re using <a href="https://github.com/Masterminds/glide" rel="nofollow">Glide</a> with a carefully-constructed Makefile.</p></pre>SmokyQuarks: <pre><p>So... I was using glide and was happy with it until a couple days ago, when I ran into this maddeningly annoying bug with Protobuf and vendoring (if your vendored version doesn&#39;t match the version that generated the Go code from your .proto files, you are screwed... even worse: it took me <em>hours</em> to figure out what the hell was going on.)</p> <p>I just switched the project to <a href="http://github.com/GetStream/vg" rel="nofollow">Virtualgo</a> which works in a similar way to a Python virtualenv and provides somewhat better isolation for your project. I&#39;m pretty happy with it so far, it allows me to install binaries from my &#34;vendored&#34; libraries, and uses <code>dep</code> for dependency management.</p></pre>Kraigius: <pre><p>I&#39;m surprised that Glide is being used tbh. The first thing I did when I wanted to start to manage my dependencies was try glide and I immediately stumbled across a bug that prevented me from updating the packages to the latest version. If it can&#39;t do something as basic as this, well I&#39;m not going to use it. So I just continued to vendor and I waited for dep.</p></pre>SmokyQuarks: <pre><p>Yeah, all the options suck to be honest. One of the most annoying things is having to keep your source code in the GOPATH to begin with. I hoped <code>dep</code> would fix that, but nah. I literally can&#39;t think of any other language that forces your code to live in a particular directory. I can&#39;t think of any other language that forces you to do that. Vendoring only solves half of the problem (keeping your versions separate from the system&#39;s) but it doesn&#39;t fix the namespacing issue.</p></pre>Kraigius: <pre><p>It&#39;s already odd for me that your code needs to live in a workspace but I guess the benefit is that I don&#39;t have to desperately try to remember where I saved my project, it&#39;s always under GOPATH.</p></pre>SmokyQuarks: <pre><p>Haha, that&#39;s a problem I never had. Old the way back to when I started programming as a hobby I&#39;ve had a &#34;~/Projects&#34; (or C:\Projects).</p></pre>