Please, configure the project to vendorize dependencies.
michelaquino
All 8 comments
I can recommend to use http://glide.sh for this.
kwk
on 11 Aug 2016
Viper doesn't provide a binary–it's a library. Vendoring in libraries is discouraged. Therefore, if you use Viper, vendoring is _your responsibility_.
moorereason
on 29 Aug 2016
@moorereason One has to understand what's going on but it is not impossible to have vendored libraries: https://forum.golangbridge.org/t/vendoring-and-multiple-versions-of-the-same-library/2010
kwk
on 29 Aug 2016
Adding vendoring in a library is indeed discouraged. You should vendor viper and its dependencies as part of your own project.
awfm9
on 8 Sep 2016
@awishformore it wouldn't do any harm if you can at least provide a glide.yaml file (for example) that lists the dependencies and their versions that you think work well with your library. This would help anybody who integrates viper into their project. You don't need to modify the import paths, they will still be "github.com/foo/bar" . But anybody who uses glide can then flatten out the libraries used by viper and fetch them in their vendor directory.
This would really help to have everybody work with supported version of viper's dependencies.
And if you don't want to vendor your dependencies, fine. You don't have to but a simply $ glide install will fetch them for you.
How can you claim your library is stable without having at least an idea which version of dependencies you're using? Defaulting to master branch doesn't sound like a good idea.
kwk
on 8 Sep 2016
I think it is premature to close this, but is also a little early to fix.
We should wait and see what comes out of this:
https://groups.google.com/forum/#!topic/golang-dev/C0x8PeHsS8g
Glide may be fine for many, but is a too opinionated choice for a library.
bep
on 8 Sep 2016
I see the point, my apologies for closing this too hastily. Let's see what comes of this.
awfm9
on 9 Sep 2016
Peter Bourgon is heading the Go deps project and he says "libraries •must not• vendor their dependencies", so that should be it:
bep
on 4 Nov 2016
Related issues
hxzhao527
·
5Comments
Giri4joyz
·
3Comments
noandrea
·
4Comments
alfmos
·
3Comments
gmaxwell94
·
5Comments
Most helpful comment
@awishformore it wouldn't do any harm if you can at least provide a
glide.yamlfile (for example) that lists the dependencies and their versions that you think work well with your library. This would help anybody who integrates viper into their project. You don't need to modify the import paths, they will still be"github.com/foo/bar". But anybody who uses glide can then flatten out the libraries used by viper and fetch them in theirvendordirectory.This would really help to have everybody work with supported version of viper's dependencies.
And if you don't want to vendor your dependencies, fine. You don't have to but a simply
$ glide installwill fetch them for you.How can you claim your library is stable without having at least an idea which version of dependencies you're using? Defaulting to
masterbranch doesn't sound like a good idea.