External-dns: About vendoring dependencies

[linki]

I would be intersted in your opinion about vendoring dependencies.

Having a glide.yaml and glide.lock is probably non-debatable but what about also copying the code under /vendor rather than fetching it from the internet?

Here are some pros and cons for vendoring as a starter:

Pros:

• The project is completely self-contained. No or broken internet connection doesn't affect ability to build the project.
• Remote changes do not affect the project at all. Repos beeing removed from Github or renamed doesn't affect the project as we always grab it from vendor when building.
• Every change of code is visible in the commit messages (apart from Go and the stdlib itself)
• No need to pull tons of libraries from Github for each CI run (Although the same data without history is under /vendor)

Cons:

• Tons of external code duplicated as part of the repository
• Makes it hard to review pull requests that add/change/remove depdencies

[mikkeloscar]

For me, not having the vendored deps part of a PR/commit with a new feature outweighs the downsides of not having it checked into the repository. It's quite annoying/hard to review a commit with 20k changed files.

The repository size also explodes because all changes to vendored content is stored in the git history meaning everyone cloning the repo has to pull 100s of MBs rather than a few KBs (this will not change anything for external-dns as the history is already there:)).

The project is completely self-contained. No or broken internet connection doesn't affect ability to build the project.

This is mostly an annoyance for development (which can be significant enough), but I assume most people who depend on external-dns for production use will depend on the official (or their own) docker image with the binary.

[linki]

We recently decided to remove the vendor folder from the repo.