<p>Hi all<br/>
Are you guys using Godep tool?</p>
<p>Thanks</p>
<hr/>**评论：**<br/><br/>skelterjohn: <pre><p>(self promotion, since I created wgo)</p>
<p>I think that godep is the wrong approach. It tries to stick dep management <em>inside</em> of 'go get'. Specifically, the fetched package will have a subdirectory for the workspace, and to build that package properly you really have to treat it as primary (eg, run 'godep go install' from inside that package's directory so that it can use the internal workspace).</p>
<p>But because of how Go works, you cannot have conflicting versions of a package in the same workspace. They're different packages, their types won't be compatible, and people are likely to get confusing errors.</p>
<p>Package versioning really needs to happen on a workspace level. That's the approach that <a href="https://github.com/skelterjohn/wgo" rel="nofollow">https://github.com/skelterjohn/wgo</a> (and also gb, if you've heard of that). It manages the workspace for you, and has some tools to vendor and to pin versions. So, it's the <em>workspace</em> that has the versioning, rather than the package. There is only one king, and it's the workspace :)</p></pre>anoobisus: <pre><p>Literally took me less than 20 minutes to update ALL of my Go projects to davecheney's <a href="http://getgb.io/" rel="nofollow">gb</a> tool.</p></pre>pierrrre: <pre><p>Can you make a "go gettable" project with gb?</p></pre>anoobisus: <pre><p>It's specifically not supported. And for "applications" rather than small libs, it makes sense.</p>
<p>The one "lib" I have has NOT been ported over to GB. If it had external dependencies... I'd have to evaluate what the best plan of action is.</p>
<p>edit: actually, the FAQ addresses this better now: <a href="http://getgb.io/faq/" rel="nofollow">http://getgb.io/faq/</a></p></pre>tehbilly: <pre><p>This is my major beef with gb. Being able to install or update a binary with a quick 'go get' is a lifesaver. I work on a variety of platforms and can manage my go based applications in a uniform way.</p>
<p>To be fair, I've only once been bitten by a problem using a single shared workspace. If gb can generate a stub main.go in the repository root that I can run I'd consider it, as I can live with running two command to install a binary. 'go get -d ...' Then 'cd ... go run main.go'</p></pre>anoobisus: <pre><p>same thing with gb though:</p>
<pre><code>git clone http://github.com/project/repo
cd repo
gb build all
./bin/<Binary name>
</code></pre>
<p>It's "four" commands instead of "two" but I hardly think that really counts here.</p></pre>james-h: <pre><p>I'm not, though I'm not dealing with production systems at the moment. However, I believe that <a href="http://getgb.io" rel="nofollow">gb</a> might be a better option.</p></pre>zero_coding: <pre><p>why gb tool is a better tool then godep?</p></pre>lavalamp945: <pre><p>One star, would not recommend.</p></pre>sharptierce: <pre><p>yes</p></pre>pierrrre: <pre><p>yes</p></pre>
