Libkv should allow to independently vendor store backends

[abronan]

We recently added the boltdb backend and now we have to vendor 10K additional LoC regardless of the fact that we use boltDB or not (in swarm for example).

Ultimately we should vendor only the stores that are relevant to someone's usage (vendoring consul/etcd/zookeeper together makes sense as it is the case to vendor boltdb/leveldb/rocksdb together potentially, etc.)

The only solution I see for now is to remove the libkv.go entrypoint and let the user import and handle the logic of instantiating the Store. The experience is not seamless but I prefer this to the solution of vendoring 10K LoC that we don't use 😕

[chenchun]

I'm even disagree with adding dependent code you need. All you need is a simple Godeps.json and all files from dependent repository should be ignored.
In java project, if you use maven to manage your project, all you need is pom.xml, others like jar, relevant dependent code should be ignored.

[vcastellm]

What about using new golang vendoring with something like https://github.com/Masterminds/glide and ignore de vendor folder?

[mavenugo]

+1 to the concept. the value of libkv is not the number of backends that the project supports. Rather its the consistent API that the application can make use of without having to hardcode the backend.
This also helps if folks want to use libkv API, but are not comfortable open-sourcing their backend that is based on libkv.

Alternative way to handle this is to provide a registration mechanism in libkv.go and let the drivers register itself with libkv. That will reverse the dependency and will force the users of libkv to import a certain libkv driver which inturn will register with libkv.go. This mechanism will still retain the ease of use and also solves the need for say swarm to not import boltdb (in other words act like what go list does. Import only what it is actually dependent on)

[abronan]

@chenchun Agreed but this would be great for users of the lib to only import the necessary backends and thus vendor only the relevant parts without even touching to Godeps.json, etc.

The problem as of now is that libkv.go imports all the backends without considering if this is going to be of use or not to the end user, so it assumes that all the backends will be used and vendored by default.

@mavenugo I really like the idea, sounds like the best compromise between the vendoring problem and ease of use :)

[mavenugo]

Thanks @abronan.