<p><a href="https://github.com/skelterjohn/wgo">https://github.com/skelterjohn/wgo</a> is a tool that helps you manage Go workspaces. Its specific focus is on letting you forget about $GOPATH and making it easier to manage vendoring and pinning dependencies.</p>
<p>One time, get wgo and its vendoring tool. </p>
<pre><code>$ go get -u github.com/skelterjohn/wgo
$ go get -u github.com/skelterjohn/vendor
</code></pre>
<p>Liberate a package! </p>
<pre><code>~$ mkdir W
~$ cd W
W$ wgo init
W$ wgo get <package managed by godep>
W$ wgo save --godeps
...list of newly pinned deps...
W$ wgo restore
...list of restored deps...
W$ wgo install <package managed by godep>
</code></pre>
<p>tada!</p>
<p>Also, way faster than a godep restore, since it does all repo fetches concurrently (though godep could easily add that functionality).</p>
<hr/>**评论：**<br/><br/>axaxs: <pre><p>Advice from me - I don't use godep so don't know what your product does. This post contains a lot of buzzwords that don't seem to affect me. So why should I, a fulltime Go programmer and contributer to the language, use this? This isn't criticism of your product but your selling of it. Tell me why I need it. People complain about vendoring in Go like they complain about generics. Neither seem to affect me much.</p></pre>sebest: <pre><p>One of the issue with go get is that it will always fetch the master branch of all the import, so if one of the libraries you depend on change its API or introduce a bug, your software will break the next time you build it (eg: on travis.ci or another computer).</p>
<p>Basically godep offers reproductible builds.</p></pre>koffiezet: <pre><p>As someone who only started using Go a bit more than a year ago, vendoring (or the lack of it) already affected me in a very unpleasant way. One of my first go projects did not compile anymore with the latest package I used somewhere. I had to manually check it out by date to just to let my app compile again - but it crashed afterwards because some other package now responded differently in a certain situation. I ended up having to manually check out 6 packages which was a major pain in the ass.</p>
<p>Now everything is vendored, but it is an ugly solution to a problem that should have been addressed in a much cleaner way by go itself. Sorry but if your toolchain pretends to do some form of package management (which Go certainly does) - it should be able to handle versions.</p></pre>izuriel: <pre><p>I havne’t had any issues with godep at all. I don’t find it “shackling.” I find it easy to use, simpler to install things and it doesn’t forgo the breakaway from the standard of Go - a single workspace. That being said, I much prefer a tool like [gom](github.com/mattn/gom) coming from a Ruby background, but it’s a lot easier to specify dependencies - however it breaks out of Go norm and modifies the GOPATH to do it’s magic.</p>
<p>I switch from gom to godep because of <a href="https://code.google.com/p/go-wiki/wiki/PackageManagementTools">this resource</a> and the subsequently linked page to Go’s endorsed approach of vendoring which is what Godep does. The tool recommend by the Go team (goven) has been deprecated in favor of Godep. Given that this is the approach they prefer and the potentially for vendoring to be integrated in to the go toolchain I would avoid any such approach that does “workspace management” to keep all of my projects in tune with the Go process for handling it.</p>
<p>The desire to constantly break away from this set path is humurous to me because the whole point of Go was to create simplicity (and it’s dependency management does that, in an albeit terribly flawed way) and now there are tools that replace “go” commands, remove the concept of workspaces and calls them “projects” (gb, which doesn’t yet support libraries very well) and so forth.</p>
<p>My advice, stick with godep - recommended by the team and potentially similar to somethign will see as a native toolchain utility in the future.</p></pre>skelterjohn: <pre><p>Thanks for the feedback.</p>
<p>The problem with godep is that it is, I believe, a time bomb. By having a fetchable package maintain its own deps, people will inevitably try to fetch ('go get') two packages with conflicting pins into the same workspace.</p>
<p>Regarding the team's recommendations and what the future will look like, I believe you're overstating things. Dave Cheney (gb author), Keith Rarick (godep author), and I (wgo author) have all been in touch recently with people on the Go team (who reached out to us) as they try to work towards the future and come up with a solution that covers all the bases in an elegant way.</p>
<p>wgo is my shot at what I believe is the most elegant way that covers all the bases. If I can't convince the community or the Go team, then it will die, and it's ok. It's not my day job :) (though I do use it for my day job).</p></pre>izuriel: <pre><p>Well I’m definitely not trying to shoot down your project in any way - I just wanted to talk about how I don’t feel like godep is holding my projects back in any way.</p>
<p>I do agree with your point, but I see that same problem with all packages. I don’t use gb, but would pass a project written with that in mind because I don’t want to have to install a secondary tool (second to go) just to handle using it. That being said, I more than ackknowledge that I’ve already done this by using Godep and placed my packaged into the same boat as anyone else.</p>
<p>One thing I don’t know (because of lack of research - all I know of wgo is what’s been passed around here recently) is whether wgo projects require wgo or not. The only thing I dislike about godep is that if you don’t have godep the builds are not actually reproducible. This put’s the onus on consumers which is quite unfortunate (IMO). Another reason I’d like to see a solution integreated into the official toolchain.</p>
<p>In the meantime, I’ve chosen one of the lesser evils out there to handle the short term. It would be great if the final product eschewed the single workspace concept. I definitely like the “project” structure better than the forced workspace structure (something along the lines of npm as it allows vendoring along with versioning to make reproducible builds, etc…</p>
<p>I’ll get off my bum and look at wgo, I’m pushing Go for our next project a lot at work and it’s on me pretty much to provide the basic setup for getting everyone up to speed on how to do things. We’re not attached to any one dependency manager yet, so it’s a great chance to experiment, having it among the team will be essential for success.</p>
<p>Thanks for the reply, by the way.</p></pre>skelterjohn: <pre><blockquote>
<p>One thing I don’t know (because of lack of research - all I know of wgo is what’s been passed around here recently) is whether wgo projects require wgo or not.</p>
</blockquote>
<p>They do not. For a wgo workspace /path/to/W, if you set GOPATH=/path/to/W everything will work fine, assuming the deps were copied in (and wgo helps you do that). gb is the same.</p>
<blockquote>
<p>Thanks for the reply, by the way.</p>
</blockquote>
<p>Thanks for being thoughtful with your critical feedback :)</p></pre>
