Doesn't flattening and using a service like gopkg.in solve this issue? Then you can have both flat structure and multiple versions of the same library since different versions of the same library appear as different packages since the import path is different.
On Thursday, April 13, 2017 at 9:47:21 PM UTC+2, JB wrote: > > Our team has run into some complicated issues regarding vendoring. The > simplest way to explain it is with an illustration. > > We have three separate repositories; Main, Foo and Bar. > > Main vendors Bar > Main vendors Foo > Foo vendors Bar > > When trying to build this code, compile errors like this arise: > > ./main.go:12: cannot use Bar.Method() (type *"Main/vendor/Foo/vendor/Bar".T) > as type *"Main/vendor/Bar".T in assignment > > > Flattening the vendor folder structure so that all vendored dependencies > (nested or not) all resolve in the same place will solve this, but if there > are actually different versions of Foo (Main depends on Bar@v1, Foo > depends on Bar@v2) then this becomes problematic once again. > > We use govendor as our dependency management tool. > > How can we deal with this issue properly? > -- 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.
