5 ms·

I've been using Go professionally since 0.8 and in production since 1.0; this is correct. Since day one we have forked every (external) package dependency in p

I've been using Go professionally since 0.8 and in production since 1.0; this is correct. Since day one we have forked every (external) package dependency in production code to our own github account and for all the constant complaining I hear, it has been very little heartache for us. This has worked great, we periodically update our forks from upstream, once or twice a year need to fixup our code to match, run our unit tests an integration tests, do a little manual testing and call it good.

deleted 11y ago
[deleted]
nothrabannosir 11y ago
Vendoring through tarball dumps of GOPATH I can understand, but how do you deal with the dependencies of your dependencies when vendoring through forking?
- rem7 11y ago
  right? Forking changes the URL of a project, so are they updating the code? I wish the go get tool would download to the vendor folder when using GO15VENDOREXPERIMENT
- ihsw 11y ago
  It does kick the can down the road, but it kicks it pretty far. I'm not the parent but your question is completely valid -- trying to get dependencies of dependencies sends us down a very deep rabbit hole. This is usually where dynamic linking and shrinkwrapping[1]/vendoring[2] start entering serious discussions. [1] http://blog.goguardian.com/nerds/shrinkwrap-not-just-for-murderers http://blog.goguardian.com/nerds/shrinkwrap-not-just-for-mur... [2] https://github.com/tools/godep https://github.com/tools/godep
- voidlogic 11y ago
  Of our 40 or so external dependencies (huge project), only a handful themselves have dependencies we needed to also vendor. Its sounds painful, but in practice it hasn't been. We actually stopped using godep, we were getting no reward for the hassle and added complexity. Unless there is a bug, or new feature we needed, we often just update this stuff when we update the Go release we are using. My thoughts; KISS until more complexity is actually needed.
  - nothrabannosir 11y ago
    > My thoughts; KISS until more complexity is actually needed. Well, isn't that exactly what this artice is about…?
- a3n 11y ago
  Wouldn't you just follow that through to the leaves?
  - gleenn 11y ago
    Wouldn't that involve changing the references in the mid-level to the leafs? Now you have to maintain changes to all the mid-level packages, sounds like not fun.

deleted 11y ago

[deleted]

nothrabannosir 11y ago

Vendoring through tarball dumps of GOPATH I can understand, but how do you deal with the dependencies of your dependencies when vendoring through forking?

rem7 11y ago
right? Forking changes the URL of a project, so are they updating the code? I wish the go get tool would download to the vendor folder when using GO15VENDOREXPERIMENT
ihsw 11y ago
It does kick the can down the road, but it kicks it pretty far. I'm not the parent but your question is completely valid -- trying to get dependencies of dependencies sends us down a very deep rabbit hole. This is usually where dynamic linking and shrinkwrapping[1]/vendoring[2] start entering serious discussions. [1] http://blog.goguardian.com/nerds/shrinkwrap-not-just-for-murderers http://blog.goguardian.com/nerds/shrinkwrap-not-just-for-mur... [2] https://github.com/tools/godep https://github.com/tools/godep
voidlogic 11y ago
Of our 40 or so external dependencies (huge project), only a handful themselves have dependencies we needed to also vendor. Its sounds painful, but in practice it hasn't been. We actually stopped using godep, we were getting no reward for the hassle and added complexity. Unless there is a bug, or new feature we needed, we often just update this stuff when we update the Go release we are using. My thoughts; KISS until more complexity is actually needed.
- nothrabannosir 11y ago
  > My thoughts; KISS until more complexity is actually needed. Well, isn't that exactly what this artice is about…?
a3n 11y ago
Wouldn't you just follow that through to the leaves?
- gleenn 11y ago
  Wouldn't that involve changing the references in the mid-level to the leafs? Now you have to maintain changes to all the mid-level packages, sounds like not fun.