abronan
import path question
I want to use libkv for now.
Could I use import "github.com/abronan/libkv" now?
I hope this repo could work completely and all path is correct.
Right now it's a bit limited because imports in this package point to original docker/libkv package. The best way right now is to use it with package manager that has support for aliasing (like glide).
@Akagi201 I agree that we should do something about it, still thinking about the best way to handle this. There are two possibilities:
-
Just rely on aliasing with package managers supporting it, like Glide as mentioned above (I think this is a simple example of how to do it).
- Upside: there is not much to change in this case, no need to rename the import paths
-
Downsides:
- Not every package manager support the option of aliasing and pointing to a fork without dirty tricks.
- It's not very welcoming to new contributions as the process will be quite hard to submit PRs (add the fork as a remote to the main repository folder, fetch changes, create new branch from abronan/master or rebase on top of abronan/master)
-
Create a new repository with a new name (to mark a clear separation from the upstream repository), renaming the import paths along the way.
-
Upsides:
- Easy to do, no brainer solution
- No convoluted process to submit a contribution
-
Downsides:
- Somewhat dirty, because we'll have to rename import paths every time we carry changes from the upstream repository. We should expect contributions to flow to the upstream repository for a while (because it is very visible under the docker GitHub org).
-
Upsides:
Aliasing is a hacky solution and, even though some of the package managers support that, dep (which will likely become official package manager) will not support it (https://github.com/golang/dep/issues/191).
rename import paths every time we carry changes from the upstream repository
That's true but it's only a simple, one-time operation which simplifies usage and contribution.
