Why is there no oficial vendoring solution?

<p>Something like &#34;go vend&#34; that simply copies from your $GOPATH/src into the vendor project seems really logical to me and I&#39;ve been wondering a lot why this hasn&#39;t been implemented yet.</p> <p>is there any statement from a go big shot about this?</p> <hr/>**评论：**<br/><br/>nicerobot: <pre><p>I don&#39;t know about a statement from &#34;a go big shot&#34; but, as the creator of <a href="https://github.com/nicerobot/git-freeze" rel="nofollow">git-freeze</a>, I wouldn&#39;t use such a tool because that&#39;s not how I want to vendor, i.e. I don&#39;t want copies from <code>GOPATH</code>, i want submodules (or subtrees) that retain a commit history for me in source control. But, as seen in literally every post where i&#39;ve mentioned <code>git-freeze</code>, plenty of people don&#39;t want to use submodules/trees, so, I suspect it was a conscious decision by the Go team not to dictate a solution to vendoring since any solution would have certainly alienated a significant number of developers. While the Go toolchain is quite opinionated, I personally believe a vendoring solution is outside the scope of the toolchain since vendoring is really about namespaces, not about how to manage the vendor folder.</p></pre>zer00eyz: <pre><p>Thank you for this! If it does what it says on the tin (subtrees) then I&#39;m going to be a happy camper!</p> <p>I have always been of the mind that I want to control my own destiny when it comes to my dependencies. If I&#39;m not committing them to my source tree they must not be that important. Storage is cheeper than lost productivity! </p></pre>nicerobot: <pre><p>I understand, especially with the recent left-pad debacle, developers can be sensitive to linking to another project as a dependency. My position is that, if a repository on which I depend disappears, I will push a version from my local build environment to a repository under my control and update my imports. I just like the lightweight nature of submodules but I added subtrees because plenty of others seem to share your view. And, along the lines of my first comment, I&#39;m not one to judge how others manage vendors. If it makes sense for <code>git-freeze</code> to support a technique, I&#39;ll consider supporting it.</p></pre>YEPHENAS: <pre><p>The Unix cp tool?</p></pre>seriouslulz: <pre><p>Because Google stores all of its code in a single repo</p></pre>skidooer: <pre><p>The official vendoring solution is to fork and maintain all of the projects you want to use in your own private git repository.</p> <p>Vendoring was introduced because the community wanted to play around with their own unofficial ideas on how to track external packages. No real consensus has been reached because they are still playing, trying to figure out what works best.</p></pre>hansdr: <pre><p>This sounds like the simplest method of controlling versions of dependencies while also dealing with the possibility of a dependency&#39;s repository disappearing. </p> <p>I&#39;m relatively new to Go, and I had expected that people would be tagging releases on the repository so that people using it could choose specific versions. However, it sounds like not too many people actually do so.</p></pre>interactiv_: <pre><p>because the go team at google barely care about these things. </p></pre>