<p>With the goal of migrating to Go 1.5 Vendoring as soon as possible, what do you feel would be a good tool to use <strong>today</strong> that would make migration of this easy?</p>
<p>The goal is to have something to use today for package pinning, that will require minimal adjustment when 1.5 hits. Thoughts?</p>
<hr/>**评论：**<br/><br/>kardianos: <pre><p>This tool isn't ready today. However I would like it to be soon. Want to help? Right now it uses import path rewrites but I would like to add support for the vendor experiment as well as other enhancements.</p>
<p><a href="https://github.com/kardianos/vendor" rel="nofollow">https://github.com/kardianos/vendor</a></p>
<p>See the outstanding issues. Also see the roadmap in the wiki section.</p></pre>natefinch: <pre><p>GB (<a href="http://getgb.io" rel="nofollow">http://getgb.io</a>) is really really close to the 1.5 model. GB currently requires a src directory at the root of your code, and a src directory at the root of the vendor directory, and doesn't support multiple vendor directories the way the 1.5 spec does... but if your project works with gb, moving it to 1.5 vendoring would just require removal of the src directories.</p>
<p>so gb would look like:</p>
<pre><code>$PROJECT/src/root_of_your_code
$PROJECT/vendor/src/github.com/foo/bar etc
</code></pre>
<p>and 1.5 would look like</p>
<pre><code>$PROJECT/root_of_your_code
$PROJECT/vendor/github.com/foo/bar etc
</code></pre></pre>oarmstrong: <pre><p>Not OP, but that's really helpful. Thanks. </p></pre>om0tho: <pre><p>The GB tool proposes a totally different workflow than the standard go tool (and replaces it). I would proceed with caution...</p>
<p>Or not. Whatevs.</p></pre>
