|
|
|
|
|
|
by jshute
4258 days ago
|
|
|
Vendoring always seemed a bit gross to me. On one hand it makes it possible to avoid build breakages when doing "go get" from master, but on the other hand it makes keeping up with master more difficult as it disassociates you from the source. I think when multiple projects involve vendoring we will end up with cuts at arbitrary places in our dependency graphs, and knowledge and manual intervention will be required to sync with modern/bug-fixed implementations. Someone gave me a good piece of advice on ethics once: if it's a problem when everyone does it, it's probably unethical. In this case we want to make life easier on our users, but from those good intentions we may actually make an ecosystem where everyone is less efficient... http://en.m.wikipedia.org/wiki/Price_of_anarchy I would personally rather intervene once to lock the entire transitive closure in a buildable state rather than manually find and update all vendored cuts in the graph. The plot will thicken with http://golang.org/s/go1.4-generate as I suspect the generate step will frequently refer to things in $GOPATH/bin. |
|
|