Approach to vendoring dependencies

[lucasgomide]

To avoid troubles with dependencies versions, the Go team's recommended approach to vending dependencies [link].

We can use godep to make it..

wdyt?

[i4ki]

Vendoring is for programs, not libraries.

[i4ki]

But we do need to create a release version of wabbit!
:-)

The project is useful for you in the current state? If so, we can release the v1.0.

[lucasgomide]

I believe that dependencies are dependencies..
So, any dependencies can to break for either programs or libraries. (As been happened on #7), or didn't ? Why should I vendoring for programs only ?

About to create a release, sgtm.

[i4ki]

Libraries shall not vendor for several reasons, but the most important is that otherwise libraries could export in their APIs types from their own vendor directory making impossible (for example) to satisfy a library interface.
.
In other words, the library and the program importing a package like "golang/x/net/context" could end up referencing different packages (depending if a vendor dir exists or not in the library path).

You could get more information in the links below:
https://groups.google.com/forum/#!topic/golang-dev/4FfTBfN2YaI
https://groups.google.com/forum/#!topic/golang-nuts/AnMr9NL6dtc
etcd-io/etcd#4913

The general advice to avoid such problems is adding vendor only to programs. But the example you give to me is a real one. The go-dockerclient isn't used in our library, but only in the test program. When we run "go test", it builds a program that uses our library to test, than it's reasonable to vendor the libs used in tests (because it's a program).

go-dockerclient is a safe dependency to vendor in our side (no one will ever import it), but the streadway/amqp is not.

[lucasgomide]

Perfect !!
I'll check your links

🚶🏻Ty @tiago4orion