Libraries are putting dependencies in vendor/

[Matt Farina]

We're seeing libraries put dependencies in their vendor/ folders while using the GO15VENDOREXPERIMENT. These libraries are meant to be consumed by other applications. When that happens an instance from location, such as a logger or database driver, isn't compatible with it in another location. And, you get binary bloat by having it multiple times.

How can we teach people some good practices to avoid these downfalls?

[Russ Cox]

On Mon, Jan 11, 2016 at 9:39 AM, Matt Farina <matt....@gmail.com> wrote:

We're seeing libraries put dependencies in their vendor/ folders while using the GO15VENDOREXPERIMENT. These libraries are meant to be consumed by other applications. When that happens an instance from location, such as a logger or database driver, isn't compatible with it in another location. And, you get binary bloat by having it multiple times.

How can we teach people some good practices to avoid these downfalls?

People are probably vendoring the dependencies for a good reason: they want to insulate their library from upstream changes to the dependency. One goal of having an agreed-upon vendor spec is to let people write down where the code came from (and ideally what the constraints are), so that when you vendor their library into your own code base, you can resolve the dependencies and pull them up higher, into your own vendor tree.

I think the way to solve the bloat and the compatibility problem is to get people to use a common vendor spec, so that no matter how they happened to put the code into the vendor directory, you as the consumer of the library can use any vendor-spec-aware tool to hoist those dependencies up higher.

That means the first step needs to be to work with Daniel Kardianos to get agreement on a spec for recording what's _in_ the vendor directory, so that we can move on to building tools that operate on vendor directories (and interoperate).

Thanks.

Russ

[Matt Farina]

First, I am a proponent of a common vendor spec. For anyone interested in why that's not moving forward please see the issues surrounding it.

Sometimes people are intentionally vendoring a version of a package. That certainly is a case.

But, there is a second case. That is people who are unaware of the consequences or what's going on. What's built in is different than good practices with reasons behind it. It's this second case I'm concerned with.