3 ms·
Vendoring through tarball dumps of GOPATH I can understand, but how do you deal with the dependencies of your dependencies when vendoring through forking?
by 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 agoright? 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 agoIt 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 agoOf 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 agoWouldn't you just follow that through to the leaves?
- gleenn 11y agoWouldn'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.