How does a committed vendor folder look like?

<p>Some example Github repo maybe. Trying to figure out this whole structure thing</p> <hr/>**评论：**<br/><br/>shadowh511: <pre><p><a href="https://github.com/Xe/site/tree/master/vendor">like this</a></p></pre>Saltones: <pre><p>Yes thanks. Isn&#39;t this like checking in other people&#39;s code into your repo? Feels a bit wrong</p></pre>shadowh511: <pre><p>Yes, it&#39;s technically wrong in that regard, but Go tooling kinda ended up needing vendoring as a hack around a proper dependency manager (<a href="https://github.com/golang/dep" rel="nofollow">dep</a> is the step in the right direction tho).</p> <p>A benefit of vendoring code is that people can get executables that are byte-for-byte the same consistently using the same source repo at a given commit.</p></pre>drvd: <pre><blockquote> <p>Yes, it&#39;s technically wrong</p> </blockquote> <p>I hear this argument a lot. But I do not understand it. Maybe you could explain it?</p> <p>If I have to ship or maintain a software product I have to keep the external code used by my own code somewhere as I cannot afford a broken product just because some external dependency vanishes from the internet. So most keep each and every dependency used once in the lifetime of the product in something like Archiva or Nexus. This is accepted best practice. On the other hand keeping the dependency in source control is considered &#34;technically wrong&#34;. I understand that it increases storage costs. But if you do not update your dependencies on a weekly basis this is not a game changer.</p> <p>Why is keeping dependencies in Archiva okay and in git not? </p></pre>Saltones: <pre><blockquote> <p>A benefit of vendoring code is that people can get executables that are byte-for-byte the same consistently using the same source repo at a given commit.</p> </blockquote> <p>Can&#39;t you get the same with the version pinning thing that dep does?</p> <p>Also, what about licenses of the packages you&#39;ve included?</p></pre>soapysops: <pre><p>You can sorta get the same effect, but there are lots of special cases like what if someone deletes their repository or what if someone hacks in and changes the code for the dependency out from under you? Also, if you have to download all the dependencies anyway to work on a project, why not include them in the git repository and be able to more precisely track changes and build tools that work across not only your code but also all of your dependencies?</p> <p>I mean this really tends to be a polarizing issue. Big companies tend to include the source code for dependencies since they already have good tooling for managing it, and it&#39;s more secure - they don&#39;t like to depend on anyone else. There are pros and cons to both sides.</p> <p>One nice aspect of Go is most Go dependencies are actually written in go, so it&#39;s easy to just compile them when needed. Many other languages actually force users to not vendor dependencies because they need to be pre-compiled or generated with various tools (eg. C/C++ libraries for Python/Ruby/JavaScript). So vendoring (and mono repos) have far fewer disadvantages when your primary language is Go.</p> <p>I personally prefer to vendor my dependencies because it just seems more efficient, but if you don&#39;t, then I don&#39;t think it&#39;s a major issue.</p></pre>shadowh511: <pre><p>don&#39;t violate the licenses :)</p></pre>dimitrios_gopher: <pre><p>I think this is a really good question. We should find two vendor folders that have been together many years and ask them their secret.</p></pre>