Github friendly vendoring

<p>Hi all,</p> <p>I&#39;m looking for some advice on GitHub friendly dependency vendoring.</p> <p>There seem to be quite a few approaches, so looking for one that best meets the following goals:</p> <ul> <li>Reproducible builds - Not getting caught out if the dependency changes in a way that breaks backwards compatibility. Or, if behaviour changes in a way that doesn&#39;t break builds, but leads to subtle bugs.</li> <li>Reproducible builds - Not having problems if branches or tags disappear, or even if a whole repo is renamed or deleted.</li> <li>Security - Prevent upstream changes (malicious or otherwise) automatically compromising our security.</li> <li>Development - Should support versioning by commits, tags and branches.</li> <li>Development - Any approach should encourage and make it easy to send fixes etc upstream, as opposed to just hacking code locally and not sharing. This would imply being GitHub fork friendly.</li> <li>Development - Should be easy to get upstream features and bug fixes when released. Ie. fork then PR.</li> <li>Build - Should be easy to download required packages, especially in a GitHub-heavy environment.</li> <li>Conflict - Probably needs to deal with dependency conflict. E.g. A depends on X and Y, both of which depend on Z. In actual fact, X depends on Z1 and Y depends on Z0 and hasn&#39;t been updated to support Z1 which isn&#39;t backwards compatible.</li> </ul> <p>We&#39;re using Gom at the moment, but end up having to do a lot of nasty module rewriting to get it to use forked version, and even then Gom automatically pulls down the upstream dependency repos.</p> <p>Thanks</p> <hr/>**评论：**<br/><br/>daaku: <pre><p>I recently switched to using <a href="https://github.com/mjibson/party" rel="nofollow">https://github.com/mjibson/party</a> for this and I&#39;m quite happy with its simplicity so far. Here&#39;s the project where I&#39;m using it: <a href="https://github.com/daaku/rell" rel="nofollow">https://github.com/daaku/rell</a>. It allowed me to put all my deps in /internal/.</p></pre>coredump777: <pre><p>I think this is the future. At least from what I read about Go 1.5, that&#39;s the way that Go is suggesting to do (an internal dir on your source that copies the external deps). Elegant and simple.</p></pre>garslo: <pre><p>I&#39;ve had some success with having one workspace for each program (or group of similar programs). You version control the whole workspace and add each package (github repo) as a subtree. This lets you freeze each package at a specific commit. Committing back upstream is a more complicated command than just &#34;git push&#34;, and it&#39;s more complicated to set up, but it frees you from shifting dependencies. You can just re-clone the whole workspace and you&#39;re ready to build.</p></pre>natefinch: <pre><p>You want godep (github.com/tools/godep). It won&#39;t fix the z1 and z2 problem, but in theory different incompatible versions should be using different import paths, so there should be no confusion.</p></pre>zeroXten: <pre><p>Ok thanks. I guess we wouldn&#39;t use the copy/vendor functionality as we&#39;d end up making a copy of a fork. That functionality could be useful for non-github dependencies, but I assume it wouldn&#39;t be able to copy some but not others. </p></pre>natefinch: <pre><p>Why would you not vendor? Forking manually seems like a waste of time and effort. It&#39;s trivial to vendor, then explode out the vendored copy into your local gopath when you need to try updating from upstream, then re-vendor. It means all that external code is nicely tucked away in a subfolder of your project, rather than polluting the namespace of your github account.</p></pre>