Vendor dependencies to allow for self-contained builds #2495
Conversation
|
Thank you for your contribution. I've just checked the OWNERS files to find a suitable reviewer. This search was successful and I've asked fturib (via If you have questions or suggestions for this bot, please file an issue against the miekg/dreck repository. The bot understands the commands that are listed here. |
|
[ Quoting <notifications@github.com> in "[coredns/coredns] Vendor dependenci..." ]
<!--
Thank you for contributing to CoreDNS!
Please provide the following information to help us make the most of your pull request:
-->
### 1. Why is this pull request needed and what does it do?
Consider vendoring dependencies.
I'll note that this suggestion has been rejected in the past, but I wanted to surface it again.
I'm relatively new to the world of Go, so it may be that there's a subtlety here of which I'm unaware, about which I'm happy to be educated.
external plugin will fail to compile if we do this:
@ # Not vendoring these, so external plugins compile, avoiding:
@ # cannot use c (type *"github.com/mholt/caddy".Controller) as type
@ # *"github.com/coredns/coredns/vendor/github.com/mholt/caddy".Controller like errors.
so we can't. Maybe gomodules can make this work.
|
Is there documentation flow on the external plugin compilation flow? Naively, I've been assuming: If "make coredns" works cleanly, then we should be good. But that's apparently not the case... Put another way, can you give me an example of an external plugin whose compilation will fail in this manner, so that I have something to use as a litmus test - if I wanted to experiment to Go modules for example? I realize it's not your job to educate me - thanks for being willing to engage in discussion on this! :) |
|
any external plugin will fail. See https://coredns.io/explugins/unbound/ for an example one, are coredns/example on github |
1. Why is this pull request needed and what does it do?
Consider vendoring dependencies.
I'll note that this suggestion has been rejected in the past, but I wanted to surface it again.
I'm relatively new to the world of Go, so it may be that there's a subtlety here of which I'm unaware, about which I'm happy to be educated.
If instead, perhaps, things have changed (and this is now acceptable), I'd love to see it merged.
2. Which issues (if any) are related?
#1523
3. Which documentation changes (if any) need to be made?