Libkv should allow to independently vendor store backends about libkv HOT 5 CLOSED

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.

from libkv.

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

from libkv.

+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)

from libkv.

@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 :)

from libkv.

Thanks @abronan.

from libkv.