On 16/07/16 15:16, Peter Mogensen wrote: > * Use gvt for vendoring everything into /vendor
You would be surprised to know that gvt uses gb internally, and both the projects exchange pieces of code and ideas ;) > But wrt. to the talk above: Didn't Dave Cheney dismiss the diamond > problem a little too fast? Sure you "cannot" do that, but you can still > end up in a situation where you depend on 2 different libraries, each > which depends on different specific version of the same 3rd package. I actually agree with Cheney's decision: http://dave.cheney.net/2015/06/09/gb-a-project-based-build-tool-for-the-go-programming-language The probability of encountering a diamond dependency conflict is so low that makes sense to treat it like a corner case and to force the final user to manually take action; providing some boiler-plate solver will never guarantee a valid consistent resolution for every single conflicting case, leading only to an increased complexity¹ of the tool. Automatically solving the diamond dependency conflict requires tampering with the Golang source code anyway, which means we are back to the square one with dirty work-arounds: with source code tampering you lose the "reliable" and "reproducible" part of your builds. One could argue that solving the diamond dependency in an automatic way has benefits per se. I can understand the allure of that reasoning, but it's not the Go way of doing things; it's like with Generics: some people like them and want them, some others don't and prefer to stick to manual implementation. There isn't an easy answer to such problems. ¹- you have to deal with graph theory, implement Breadth First and Depth First algorithms, impose barriers and fences all over the PM; I personally don't see the advantage considering its complexity vs the little outcome. It's easier, and faster, to manually solve the conflict. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
