Vendor all dependencies? #1523
Comments
|
This go get "version guarding" was added about a month ago (#1370). There isn't really an explanation as to why vendoring is not used. Vendoring has its own set of pain points. @yongtang @miekg The change caused similar breakage as you describe in the continuous integration tests when an external plugin (forward) was included by default in the coredns Makefile. The temporary fix (#1435) was to ignore the failure of the step in the Makefile. This had the effect of not re-getting coredns/coredns, which you already have at correct version if you are building from a branch. IMO, it seems like Go should know this and not be confused, but maybe there is ambiguity there and I'm only seeing one case. Since then, forward has been moved into coredns/coredns, so its no longer an external plugin. |
|
We try to vendor everything, but because of external plugins we can't sometimes. This is situation is pretty terrible. Go 1.9 and type aliases might make this better, see #792 for instance. |
|
You make a good point about the difficulty that external plugins represent. However, they can be vendored too for custom builds, if all dependencies live in What do you think? |
|
[ Quoting <notifications@github.com> in "Re: [coredns/coredns] Vendor all de..." ]
You make a good point about the difficulty that external plugins represent.
However, they can be vendored too for custom builds, if all dependencies live in `./vendor` there should be no issues to build coredns.
What do you think?
this would mean that all current existing, external plugins, don't compile
anymore. Go vendoring is very much a work in progress and has some very rough
edges. In this case we (core CoreDNS) should make it easy for external plugin
developers even if this means it will be harder for CoreDNS itself.
|
|
If there are things we could to make it easier for CoreDNS devs we should most definitively do that, while keeping in mind that the experience for plugin developers should be seamless |
|
I hope |
|
Yep, there’s hope for a brighter future! Thanks for your feedback you all. |
Hello,
I'm having a bit of trouble getting reproducible builds with CoreDNS, which makes tracking down issues much harder.
I have a build that I made 5 days ago and worked just fine, but the build I'm making today have broken the config we used.
Most of the pain comes from the custom build process that CoreDNS uses with its makefile, which does
go get+git checkoutto lock down dependencies, where this could be better served by leveraging the vendor folder.There are already a bunch of dependencies checked in into the vendor folder, my question is why not vendor all dependencies? That way building coredns would basically just be
We can't just use one of the tagged releases because we add external plugins so we need to rebuild CoreDNS, and the
go getsteps fail if the coredns repo is checked out in a non-master branch or a branch that does not exist on the remote repo (due to interdependencies between coredns and plugins).I'd love to hear about how people have addressed those kinds of problems as well, maybe I'm not approaching this the right way.
The text was updated successfully, but these errors were encountered: