Best practice for vendoring in libraries?

<p>By library I mean a set of packages that don&#39;t have a main package. If your library depends on a particular version of a third party package then should you vendor it in your library&#39;s repository?</p> <hr/>**评论：**<br/><br/>kardianos: <pre><p>If the consumers of the library repo all use a tool to &#34;flatten&#34; the vendor tree, then by all means, please vendor the library&#39;s dependencies.</p> <p>If your consumers of the library just use &#34;go get&#34;, then you may want to hold off now checking them in them. It may still be worthwhile to copy locally and check-in dependencies that are purely used within your project, are not exposed in any API, and where a duplicate package won&#39;t hurt anything.</p> <p>Even if you don&#39;t check in your source code, you could still include a meta-data file that can pull down the exact versions you used so you can test with consistent revisions and people who use a compatible tool can also be offered those revisions. If you use govendor (github.com/kardianos/govendor) this would be equivalant to vendoring your deps, but then adding &#34;vendor/*/&#34; gob to the ignore file. This will check in the meta-data file but leave the dep sources. Then you can run &#34;govendor sync&#34; to pull in those exact revisions.</p></pre>jonbonazza: <pre><p>Convention is that you do not vendor dependencies for libraries. If an app pulls in a library, the vendoring tool (e.g godep) should vendor transitive dependencies as well. </p></pre>nicerobot: <pre><p>I wrote <a href="https://github.com/nicerobot/git-freeze" rel="nofollow">git-freeze</a> to facilitate this. It defaults to supporting submodules but can also utilize subtrees. Here&#39;s a <a href="https://www.reddit.com/r/golang/comments/492w0u/do_you_like_go_get_want_to_vendor_your_code/" rel="nofollow">discussions of using this technique</a>.</p></pre>kardianos: <pre><p>Question: The author specifically mentions vendoring for &#34;library&#34; repos, if you use &#34;git-freeze&#34; on a &#34;library&#34;, won&#39;t that make it impossible for importers of the library to use the same transitive dependencies? (In other words, it won&#39;t flatten them.) If true, that is my biggest issue when someone suggests git submodules as a generic way to handle the vendoring.</p> <p>I do see how submodules could be useful for an end product with limited scope where all dependencies are in git. But I don&#39;t see it as a general solution.</p> <p>Am I missing something or is that approximately correct? I&#39;d like to adjust my thinking if I&#39;m wrong.</p></pre>nicerobot: <pre><p>All dependencies don&#39;t have to be git repositories, just able to be submoduled by git, which includes bzr and hg. Additionally, <code>git-freeze</code>allows subtrees instead of submodules.</p> <p>If by &#34;transitive dependencies&#34; you mean <code>A -&gt; B -&gt; C</code> and <code>A -&gt; C</code>, and you want both <code>C</code> libraries to be the same, that&#39;s a horrible idea. It&#39;s only slightly acceptable if you own all the libraries involved. If you don&#39;t own <code>B</code>, then you have no idea what version of <code>C</code> <code>B</code> imports. The entire reason for using vendor is isolation.</p> <p>If you don&#39;t want the isolation provided by vendoring, simply don&#39;t vendor and keep some or all of your libraries &#34;flat&#34; in GOPATH. The two are not mutually exclusive.</p> <p>I&#39;ve used submodules to manage dependencies to great effect since Go 1.2. <code>git-freeze</code> is just a formalized version of this proven solution.</p></pre>