[Idea] Go should add options for vendoring dependencies

<p>Here is my idea (inspired by godep, but integrates into Go):</p> <pre><code>// Proposed changes to the &#34;go get&#34; command: go get [--save] [ &lt;pkg&gt; [--branch] [--tag] [--commit] ] --save // Saves package to _internal within the project directory // and adds the relevant info to deps.json (commit, tag, branch, etc.) // deps.json should be located in the project directory rather than _internal // for easier access. // if no package is supplied, &#39;go get --save&#39; will save all // dependencies in the project. </code></pre> <p>Then, a simple change to <code>go build</code>:</p> <p>Right now it checks $GOPATH and $GOROOT for packages. Simply change it to check _internal first.</p> <p>Adding this to Go would help unify the ecosystem so that it is easier for everyone to build everyone else&#39;s packages without having to get package manager X and have more version control over the current <code>go get</code> implementation.</p> <p>Thoughts?</p> <hr/>**评论：**<br/><br/>dsymonds: <pre><p>You might want to see the golang-nuts archives for the dozens of other similar proposals that have been previously made.</p></pre>kardianos: <pre><p>Ideas like this has been proposed. Some of these ideas were even made into a proposed patch for the go tools.</p> <p>The go team has committed to import re-writes and vendoring.</p> <p>The question should no longer be &#34;what&#34; for the go community. The open question that was raised was &#34;what should the vendor file be?&#34; Let&#39;s help by answering that question.</p> <p>It is totally cool for internal organizations and groups to come up with an internal representation. I can&#39;t help feel it is counter productive to continue to say &#34;yeah but, I know better! Here&#39;s MY solution.&#34; Let&#39;s work together and work on what needs to be in the vendor file and what it should look like. If no one else has a proposal, consider this one: <a href="https://github.com/kardianos/vendor-spec" rel="nofollow">https://github.com/kardianos/vendor-spec</a> . It is more then just a struct definition with a few comments.</p></pre>rrr00bb: <pre><p>It should definitely be easy to specify the commit at which an import is done. This is a more general problem with multiple repos though. I wish git had a standardized solution to it. Git submodules and subtrees seems really wrong. I think it&#39;s clear that projects should have a top-level repo that just tracks all the source and binary artifacts. It&#39;s unclear whether it&#39;s a good idea to ever write commits into commits. Perhaps the top-level repos should not explicitly mention commits, but expect that the repos that they reference are tagged to match up with that top-level repo&#39;s commit.</p></pre>ThisAsYou: <pre><p>I didn&#39;t know that. Thanks for all the info! The spec you linked looks good to me. Do you know if they plan to have this figured out for 1.5?</p> <p>Edit: a word</p></pre>kardianos: <pre><p>It is my understanding that they hope to have a vendor file spec defined this fall around when 1.5 is release.</p> <p>However, because google has a single source tree and runs from the head version, they have expressed a desire for the community to come up with a spec that they can then bless. So I think the timeline somewhat depends on the community.</p></pre>ThisAsYou: <pre><p>I really like the spec you have. One thing I&#39;d really like to see is an easy ability to have project-specific GOPATH&#39;s since you may have different versions of packages for different projects.</p></pre>