<story><title>Go at Digital Ocean</title><url>https://speakerdeck.com/farslan/go-at-digitalocean</url></story><parent_chain><item><author>arianvanp</author><text>The go vendoring stuff and GOPATH sounds like a complete nightmare to me.  Also the fact that imports are full git URLS sounds totally crazy.   Is `dep` fixing all that stuff?  Last time I checked out go a few years ago, I didn&amp;#x27;t continue because I found the story of actually installing dependencies and keeping track of versions very confusing. You couldn&amp;#x27;t even `go get` a specific git tag or something.&lt;p&gt;I&amp;#x27;m happy that there seems to be some movement. But now we have godep, govendor, glide, dep. and every project uses one or the other. Are they all compatible? Or is it a minefield?</text></item></parent_chain><comment><author>imsofuture</author><text>Go vendoring gets &lt;i&gt;such&lt;/i&gt; a bad rap undeservedly. In practice it&amp;#x27;s the simplest and most straightforward dependency system (since 1.4&amp;#x2F;5 added vendoring) I&amp;#x27;ve used.&lt;p&gt;Step 1: Check out code that you want to use. That&amp;#x27;s actually the only step and you can do it by hand, or with one of a multitude of tools. All the tools differ slightly, and any metadata or manifests or things like that they do aren&amp;#x27;t compatible, but the code they put in your repository is, enabling anyone to clone a repository, and instantly build the exact version of all your dependencies.&lt;p&gt;Imports also &lt;i&gt;aren&amp;#x27;t&lt;/i&gt; full git URLs, they &lt;i&gt;can be&lt;/i&gt; as a convenience that tells you where to get a package. You can&amp;#x27;t `go get` a specific tag, but that&amp;#x27;s fine, because `go get` isn&amp;#x27;t a package or dependency manager, it&amp;#x27;s just a convenience to grab code to your system, not to freeze a version as a dependency into your project.&lt;p&gt;Frankly, the amount of people that put their nose in the air at go is just fine with me, just makes it more of a &amp;#x27;secret productivity tool&amp;#x27; I guess.&lt;p&gt;Edit: not to say it wouldn&amp;#x27;t have been nice if `dep` had been the one blessed path at version 1. Still, I have extremely little to complain about with the language and tooling since 1.4&amp;#x2F;1.5.</text></comment>
<story><title>Go at Digital Ocean</title><url>https://speakerdeck.com/farslan/go-at-digitalocean</url></story><parent_chain><item><author>arianvanp</author><text>The go vendoring stuff and GOPATH sounds like a complete nightmare to me.  Also the fact that imports are full git URLS sounds totally crazy.   Is `dep` fixing all that stuff?  Last time I checked out go a few years ago, I didn&amp;#x27;t continue because I found the story of actually installing dependencies and keeping track of versions very confusing. You couldn&amp;#x27;t even `go get` a specific git tag or something.&lt;p&gt;I&amp;#x27;m happy that there seems to be some movement. But now we have godep, govendor, glide, dep. and every project uses one or the other. Are they all compatible? Or is it a minefield?</text></item></parent_chain><comment><author>weberc2</author><text>GOPATH isn&amp;#x27;t a real problem; it&amp;#x27;s just a search directory like PATH or PYTHONPATH or CLASSPATH or NODEPATH, and it has a default value that makes it painless. Vendoring can be truly painful, but `dep` aims to fix that. Imports are &lt;i&gt;not&lt;/i&gt; git URLs or indeed any kind of URLs; they&amp;#x27;re just directory paths into your GOPATH which the `go get` program can use if the directory path resembles the URL of a git (or hg&amp;#x2F;bzr&amp;#x2F;svn) repo. Don&amp;#x27;t think of `go get` as a package manager; think of it as a convenience utility to play around with a package before locking down the version via vendoring. Go&amp;#x27;s package management has a lot to improve on, but many of the common complaints are misinformed.&lt;p&gt;&amp;gt; I&amp;#x27;m happy that there seems to be some movement. But now we have godep, govendor, glide, dep. and every project uses one or the other. Are they all compatible? Or is it a minefield?&lt;p&gt;They&amp;#x27;re not all compatible, but it&amp;#x27;s not really a problem because (last I checked) the prevailing philosophy was &amp;quot;libraries should not vendor--only binaries&amp;quot; which is to say &amp;quot;libraries shouldn&amp;#x27;t specify versions for their dependencies; the downstream binary projects should figure out what versions of each library should be used to build the binary&amp;quot;. This means &lt;i&gt;dependency tool compatibility&lt;/i&gt; isn&amp;#x27;t a problem because the dependency tooling punts on the dependency-resolution problem altogether, which seems like an even bigger problem.&lt;p&gt;Remember that this is only painful if you&amp;#x27;re trying for deterministic builds, and in the absolute worst case, you forego Go&amp;#x27;s build tooling and use something like Nix. This is absolutely not a reason to change language.</text></comment>